[plt-scheme] no #!eof

On Tue, Apr 15, 2008 at 09:26:50AM +0200, Jens Axel Soegaard wrote:
> Andrew Reilly wrote:
> >On Tue, Apr 15, 2008 at 12:55:40AM -0400, Abdulaziz Ghuloum wrote:
> >>On Apr 15, 2008, at 12:18 AM, Andrew Reilly wrote:
> >>Have you never seen an eof midstream?
> >
> >Honestly, no.  If it's in the middle, it clearly can't be at the end.
> 
> Puzzle: What is the expected output of the following?

[example of the sort of read/extend-file sequenced loop that I
alluded to, earlier]

Coming from a C world, I'd expect the first EOF to be sticky, as
per the following commentary from the getchar -et-al man page:

     If successful, these routines return the next requested object from the
     stream.  Character values are returned as an unsigned char converted to
     an int.  If the stream is at end-of-file or a read error occurs, the rou-
     tines return EOF.  The routines feof(3) and ferror(3) must be used to
     distinguish between end-of-file and error.  If an error occurs, the
     global variable errno is set to indicate the error.  The end-of-file con-
     dition is remembered, even on a terminal, and all subsequent attempts to
     read will return EOF until the condition is cleared with clearerr(3).

I take it that with-input-from-file must do a clearerr behind
the scenes, if there is more to be read.  I can't say that I've
ever tried to read beyond an end-of-file using read(2), and the
man page isn't especially clear about what happens there.  Since
read on real files is essentially a (fseek+read) every time, I
concede that it's possible (likely, even), that subsequent reads
will provide more data.  On the other hand, read(2) doesn't have
an explicit end-of-file indication, other than short read
without error.

For kicks, I just ran it on 3.99.0.23, and it produced a
sequence of lines of #<eof> at about 1-second intervals.  I
guess that just goes to show that mzscheme is behaving as I
expected.  So, yay!

Cheers,

-- 
Andrew