[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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.