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)
|
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.