[R6RS] I/O

Anton van Straaten anton at appsolutions.com
Tue Jun 27 04:50:00 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.

The SRFI also suggests that SRFI-compliant equivalents of 'read' and 
'write' be named 'read-datum' and 'write-datum'.  These would presumably 
also require a port argument.

One way to continue to support the "current port" feature, if that's 
considered desirable, would be to have another small I/O library, which 
would contain the following procedures (more or less), all with the same 
"current port" semantics as R5RS:

read		; conceptually implemented in terms of read-datum
write		; and write-datum in the port-i/o lib
display  	; see note below

This library could be used on its own, or in conjunction with the 
port-i/o library.  I've omitted default-port versions of 
read|peek|write-char, because

Of course, these procedures could also be relegated to the R5RS 
compatibility library, possibly one specific to R5RS I/O.

The SRFI raises the issue of 'display' being underspecified and suggests 
a formatted output procedure be specified instead.  However, if we're 
not tackling that for R6RS, then 'display' and 'newline' probably also 
belong in the proposed library.


On 2006-06-17, Mike wrote:
> I've committed up-to-date versions of the I/O SRFIs to the repository
> at srfi/io.  The changes I made wrt the versions currently on
> srfi.schemers.org are:
> - various clarifications and spec tightenings requested in the phone
>   conference
> - "The return values are unspecified." -> "The unspecified value is
>   returned."
> - #f -> end of file object
> - blob -> bytes
> - Symbols for buffer modes.
> - Enum-sets for file options.
> - Predicates for the various position-related procedures.
> - removed `newline'

More information about the R6RS mailing list