But there's one significant difference between C and Haskell, which is applicable in the case of Matt's program. In C, any line-buffered output streams are automatically flushed when a read from an unbuffered or line-buffered stream can't be satisfied from its buffer.
Interesting. I didn't know this. Maybe we should match this behaviour, or provide a write-string-and-flush function. It seems like this issue is causing an undue amound of trouble.
I wrote GHC's IO library, and deliberately didn't include this feature. The previous version of the library did have such a feature, specifically for stdin/stdout. Note that the report doesn't say we must do this. The reason I didn't include the feature is because I can't see a way to do it right. Flushing *all* line-buffered handles (the ANSI C way) doesn't seem right. Flushing stdout just because we read from stdin is not right, because the two streams might refer to completely different I/O objects. Perhaps we should attempt to detect when there are two streams connected to the same I/O object (file, pipe, tty, whatever) and enable the magic flushing then. But now do I have to explain to people how this works? I suppose we could take the view that extra flushing is basically harmless, so it doesn't matter that we flush a bunch of Handles more often than we need to. The advantage of the current scheme is that it is easy to understand and explain; the library doesn't try to do clever stuff behind your back. The disadvantage is that it catches people out, and it sometimes requires you to import IO in an otherwise Prelude-only program. I'm more-or-less agnostic - if there's a way to avoid catching people out without introducing too much overhead or complicated rules that we have to explain, then I'll happily implement it. Cheers, Simon