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