Re: A few random I/O proposals

[Pavel Curtis <Pavel@parc.xerox.com>]

There've been a bunch of I/O-related topics discussed recently; here's my two
cents:

++ Error-returns vs. raising conditions

I agree with Jinx that returning #f on error is a bad idea.  It has a number of
problems, including (1) code that must perform validity checks on every
returned value is very hard to read, since the expected case is so obscured,
(2) such code is error-prone because there are so many places that much be
checked, and (3) a single error value, like #f, can't provide enough
information about what went wrong (e.g., did the file not exist, was it not
readable/writable by me, is it of a different `type' than expected [for file
systems with file types], etc.).  A reasonable condition system fixes all of
these problems.

++ Flushing output

I think that the right solution here, regardless of whether or not the Scheme
I/O system grows out of its `toy' status, is a recommendation to
implementations that, if (current-input-port) and (current-output-port) both
refer to the same interactive I/O device (e.g., terminal), then operations
getting input from (current-input-port) should flush all pending output on
(current-output-port), if any.  It might also be useful to have a
output-flushing procedure for use in other situations, but I that would be less
interesting until such time as Scheme had a more well-flushed-out I/O
architecture.

++ String ports

Before SchemeXerox switched over to the module system, we used what I think are
the Chez Scheme names for these procedures: OPEN-INPUT-STRING,
OPEN-OUTPUT-STRING, and GET-OUTPUT-STRING.  An important issue to resolve is
the state of an output string port *after* a call to GET-OUTPUT-STRING.  Is it
still open for use?  If so, is any new output appended onto the end of the
string that GET-OUTPUT-STRING returned or is the port's contents reset to
empty?  In the latter case, what guarantees does one have about sharing between
the returned string and the port's buffer if any?  Finally, what is the effect
of my mutating the string given to OPEN-INPUT-STRING?  There are a number of
reasonable sets of answers to these questions; if string ports are added to the
report, some particular set of answers should be specified.

++ Scheme I/O is a toy

Granted, but I think that the issues involved in `maturing' it are more complex
than some of the recent postings might imply.  In particular, I think that the
proposals for
	(MAKE-OUTPUT-PORT <output-proc>)
and
	(MAKE-OUTPUT-PORT <write-proc> <close-proc>)
are way too simplistic for serious use.  I recommend that those folks
interested in such issues take a look at the Modula-3 I/O system, which
provides a much more reasonable model for programmer-defined port classes.  I
don't claim that it's the final solution, but it was the best model I could
find when I designed and implemented the SchemeXerox I/O subsystem.  (A copy of
the main SchemeXerox I/O interface files is available for FTP from host
`parcftp.xerox.com' in `/transient/sx-io-interfaces.shar'.)

I also don't think that we should adopt a POSIX-like interface for I/O, since I
believe that's too low-level and unportable (esp. to non-POSIX systems... :-).
I wouldn't mind collaborating with others on the development of a standard set
of Scheme bindings for POSIX functionality (we are part-way through doing this
for use in SchemeXerox), but I think that should be a separate effort from
describing the language-level I/O facilities.

	Pavel