[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: current input & output ports

This page is part of the web mail archives of SRFI 68 from before July 7th, 2015. The new archives for SRFI 68 contain all messages, not just those from before July 7th, 2015.



On Fri, 17 Jun 2005, Alex Shinn wrote:

> How do you propose to give access to stdin and stdout?

Those are two very Unix-centric resources, which is not something I'd
like to see Scheme standardized on except in an interface specifically
to Unix, such as a scsh SRFI.  (Note, by the way, that there are
STANDARD-INPUT-WRITER & STANDARD-INPUT-READER already.)  However, my
complaint is more with the mechanism of a global 'current input port' &
'current output port' afforded special status among the I/O system so
much so as, for example, to destroy useful argument conventions; as I
suggested, there could still be items in the dynamic environment used
for things like terminal interaction ports, or, in a hypothetical Unix
interface, stdin & stdout ports.

(T, for instance, worked in the way I suggest; it still provided access
to stdio ports via settable procedures STANDARD-INPUT & STANDARD-OUTPUT
as well as potentially separate terminal ports with TERMINAL-INPUT &
TERMINAL-OUTPUT.  The I/O-related procedures all required their first
arguments to be ports, except in a couple cases (like PRINT, where the
object being printed could specialize itself); there was no general
'current input port' or 'current output port.')