Here goes nothing..

[C.Reinke]

> fyi, the fix implements what the Report prescribes, but I
> don't agree with it -- getLine ought not raise an exception
> on EOF when having read in a partial line. As is, you will lose
> input if it isn't terminated by a newline. Not too cool.

Oops. I didn't notice that. In fact, I'm tempted to see that as an
oversight in the example implementation in the Prelude, which uses
getChar without catching exceptions. But you're right, the Prelude
given in the Report functions as a spec, so the current Report
requires this odd behaviour. Not cool indeed.

> > Btw, is there a way to indicate end-of-input in Hugs?
> 
> Yes, you can (by being EOT-savvy):
> 
> getLine :: IO [Char]
..
> Whether or not this should be done by Prelude-provided functions
> like 'getLine', 'interact' and 'getContents' is worth giving some thought.
> There is a risk of introducing breakage though, as binary data read
> in via stdin will then be interpreted in unintended ways.

Wouldn't it be better to have the Hugs prompt (or readline?)
translate into EOF, instead of making getLine and friends EOT-aware?
That would also avoid the breakage.

Or would that need a separate thread for the evaluator?  Why does
EOF arrive as EOT in the first place (the Hugs main loop itself
exits on CTRL-D under unix, but not under windows, so there is some
OS-dependency leaking in)? How do the shells make it work properly
(even cygwin's bash under windows)?  Sadly, it's been a long time
since I looked into this kind of things..

Claus