[R6RS] I/O

Anton van Straaten anton at appsolutions.com
Mon Jul 10 11:19:32 EDT 2006


>>One issue which the Port I/O SRFI raises, which also affects the 
>>core/library split, is the fate of R5RS procedures which support a 
>>"current port".  The Port I/O SRFI redefines some of these procedures to 
>>require a port argument, e.g. read-char, peek-char, and write-char.
> 
> 
> Please forgive me if I've forgotten something important about port SRFI or
> an earlier discussion, but why are these now going to required a port
> argument?  What's wrong with including a current port and allowing the port
> argument to be optional?  

SRFI 81 (Port I/O) contains the following in its Design Rationale 
section, under "Optional ports and argument order":

"The argument order of the procedures in this SRFI is different from 
R5RS: The port is always at the beginning, and it is mandatory. For a 
rationale, see the message by Taylor Campbell on the subject."

The message referred to is from the SRFI 68 (Comprehensive I/O) discussion:
http://srfi.schemers.org/srfi-68/mail-archive/msg00031.html

> It's a nice convenience and also helps when
> teaching the language.

There's also some merit to having a consistently-positioned, required 
port argument.  But we could have it both ways by leaving the port-i/o 
library (i.e. SRFI 81) as it is, and having a separate, smaller library 
of high-level I/O procedures (like READ) which support a current port.

Conceptually, this smaller library would be a convenience layer over the 
port-i/o library.  It might contain many of the procedures that were 
provisionally placed in the "r5rs-i/o" library (see 
draft/corelib/library-contents.html in SVN).  I'll list those here for 
convenience:

call-with-input-file call-with-output-file current-input-port 
current-output-port display open-input-file open-output-file port?
read with-input-from-file with-output-to-file write

BTW, regardless of what else we do, call-with-input-file and 
call-with-output-file don't really belong in r5rs-i/o.  If they're not 
going to go in the core, then a high-level I/O convenience library might 
be a good place for them.

Anton




More information about the R6RS mailing list