[plt-scheme] no #!eof

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.

> Well, I haven't invented the  
> concept. :-)

Are you talking about putting a control-Z character into the middle of a
DOS text file?  I thought that was a bug then, too.

> Watch:
> 
> Welcome to MzScheme v3.99.0.18 [3m], Copyright (c) 2004-2008 PLT  
> Scheme Inc.
> > (list (read) (read) (read) (read))
> ^D
> 12
> ^D
> 13
> (#<eof> 12 #<eof> 13)

The nice PLT people seem to have fixed that behaviour, at least
in DrScheme:

Welcome to DrScheme, version 3.99.0.23-svn13apr2008 [3m].
Language: Module custom.
> (list (read) (read) (read) (read))
(shared ((-1- #<eof>)) (list -1- -1- -1- -1-))

There didn't seem to be any way to type a control-D to mark EOF
in the little dialog that popped up, but pressing the big yellow
EOF button did what I expected.

I'm pretty certain that this is the behaviour that you'll
get in C, too.  (I.e., ^D tells the shell to close the stdin
pipe, which the program sees as the end of file.  There's just
no coming back from that, no matter how many reads you do
afterwards.)

I have tried the same thing in mzscheme, and it behaves the way
that you describe.  I believe that's a bug, because a control-D
in that context is just a control-D, not an EOF.  It should have
been reported and read as such.  Actually, I think that the
mzscheme top-level read is a bit strange: (list (read-char))
returns (#\newline) immediately, without waiting for a character
from the user.

> An eof marks the end of one segment in an input stream.

In what environment?  In unix, you have pipes, sockets and
files to read, and none of them get to EOF until then end.

Hmm.  I suppose that you could make a file read loop see
multiple EOFs by appending to the file after seeing an EOF, and
then having another go.  There are issues of sequence and timing
there, though.  There's no way to pre-create a file that will
produce that behaviour on its own.

> Reading  
> again gets you to the next segment, and so on.  So, this behavior  
> makes reading #!eof in a stream consistent with reading a ^D in stream:
> 
> Ikarus Scheme version 0.0.3+ (revision 1450, build 2008-04-14)
> Copyright (c) 2006-2008 Abdulaziz Ghuloum
> 
> > (list (read) (read) (read) (read))
> ^D
> 12
> ^D
> 13
> (#!eof 12 #!eof 13)
> > (list (read) (read) (read) (read))
> #!eof
> 12
> #!eof
> 13
> (#!eof 12 #!eof 13)

OK, so Ikarus has the same bug.  That doesn't make it a good
thing.

Cheers,

-- 
Andrew