I/O proposal

[CPH%MIT-OZ@MIT-MC.ARPA]

    Date: Sunday, 17 March 1985  11:37-EST
    From: Bill Rozas <JINX>

    1.	Having a way to detect the end of file is needed, beyond that,
    both alternatives (eof? or *eof*) can be trivially implemented on top
    of the other.  I don't feel strongly about either, but I tend to agree
    with Kent Dybvig since I view *eof* as more flexible.  If the other
    option (eof?) is chosen, I would much rather have the name be
    eof-object? .

I don't think that *EOF* is a good idea, for the following reason: if
the I/O primitives are expected to return this object, they will have
to return it, and if they are written in assembly or some other
non-Scheme language it would require them to do a variable reference.
Or, at the very least, to have some kind of Scheme wrapper that either
passed them the eof object, or detected that they had returned some
other object and substituted that one.

I vastly prefer the idea of a small fixed set of end of file objects,
and I wish that I had thought up the idea myself.  However, I agree
that EOF-OBJECT? is a much better name.

If it is felt that there is a need for something like *EOF*, I would
feel better about having a procedural binder, something like

(WITH-EOF-OBJECT <object> (LAMBDA () ...))

which would give the implementer more freedom.

    2.	I disagree that the programmer should not be able to change
    the current i/o streams. The debugging problem can be trivially fixed
    if the error system/debugger always installs the appropriate stream,
    and this can be accomplished easily by appropriate
    with-input-from-stream and with-output-from-stream.

This has been my experience -- we have had this stuff running for
quite some time without problems.