current input & output ports Taylor Campbell (17 Jun 2005 01:32 UTC)
Re: current input & output ports Alex Shinn (17 Jun 2005 01:51 UTC)
Re: current input & output ports Taylor Campbell (17 Jun 2005 04:46 UTC)
Re: current input & output ports Per Bothner (17 Jun 2005 06:46 UTC)
Re: current input & output ports Michael Sperber (17 Jun 2005 21:23 UTC)
Re: current input & output ports Taylor Campbell (17 Jun 2005 23:53 UTC)
Re: current input & output ports bear (19 Jun 2005 18:51 UTC)

current input & output ports Taylor Campbell 17 Jun 2005 01:40 UTC

One thing that has always bothered me about Scheme's I/O system is the
seemingly random presence of 'current ports.'  I haven't been able to
find a rationale for the existence of the mechanism, and exactly what
the 'current {input,output} port' is meant to be used for has never
been clear to me.  Not only is the mechanism itself vague, but it also
introduces unnecessary complexities in the interface: because the port
argument to many operations is optional (which I believe Mike doesn't
like anyway), the port must go last, which skews the possibility of
other optional arguments and which is contrary to the very common
convention of putting the important aggregate datum in the first
argument.  Finally, the stream interface has no such similar 'current
input stream' or 'current output stream,' so the stream operations are
inconsistent with their port counterparts with optional arguments.

I recognize that it can be useful to store different kinds of 'current
ports' in the dynamic environment, such as a port for general noise
output, a port for error output, or ports for terminal interaction.
But I don't think that the 'current input & output ports,' as outlined
by R5RS & the current SRFI document, suit any of these roles very well,
and I see no reason to make a special case for two vaguely specified
ports so that the argument conventions of all of the port operations
are skewed with respect to optionality and inconsistent with their
stream I/O counterparts.

Now, I realize that this would be a major change that would break a
lot of code, but, unless a strong rationale can be provided for the
current input & output port mechanism, I propose to remove the current
input & output ports, make the port arguments to all of the operations
required, and move the argument to the front of the argument list.

Here is a complete listing of all of the procedure prototypes that my
proposal for removing the current input & output ports would change
from the current SRFI document:

  (READ-U8VECTOR-SOME input-port) -> u8vector or #F
  (READ-U8 input-port) -> u8 or #F
  (READ-U8VECTOR-N input-port n) -> u8vector or #F
  (READ-U8VECTOR-N! input-port u8vector start count) -> integer or #F
  (READ-U8VECTOR-ALL input-port) -> u8vector or #F
  (READ-STRING input-port) -> string
  (READ-CHAR input-port) -> char
  (READ-STRING-N input-port n) -> string
  (READ-STRING-N! input-port string start count) -> integer or #F
  (READ-STRING-ALL input-port) -> string or #F
  (PEEK-U8 input-port) -> u8 or #F
  (PEEK-CHAR input-port) -> char or #F
  (EOF? input-port) -> boolean
  (DISPLAY-U8VECTOR output-port u8vector)
  (DISPLAY-U8 output-port u8)
  (DISPLAY-U8VECTOR-N output-port u8vector start count)
  (DISPLAY-STRING output-port string)
  (DISPLAY-CHAR output-port char)
  (DISPLAY-STRING-N output-port string start count)
  (NEWLINE output-port)
  (FLUSH-OUTPUT-PORT output-port)

Additionally, the procedures CURRENT-INPUT-PORT, CURRENT-OUTPUT-PORT,
CALL-WITH-CURRENT-INPUT-PORT, & CALL-WITH-CURRENT-OUTPUT-PORT, would
all be removed.  The current error output port could still remain, and
I'd also recommend possibly adding a current noise output port, but it
is of little significance.

I also have some suggestions for how to take advantage of the new
possibilities for making some arguments optional introduced by the
elimination of the current input & output ports, but that can be left
for another mail.