An IO Question from a Newbie

[Simon Marlow]

> > 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