Haskell 98: Behaviour of hClose

Glynn Clements glynn.clements@virgin.net
Wed, 18 Sep 2002 20:50:03 +0100


Simon Peyton-Jones wrote:


> | 2. Is there actually anything special about the treatment of stdin, or
> | does this apply to any input stream which is associated with a
> | terminal?
> 
> I'm proposing just stdin.  My motivation is to make simple stupid
> programs work right.

Argh. Too much of this and you end up with a language which isn't
suitable for anything other than "simple stupid programs".

If you're considering adding "magic" behaviour, the first question
should be "if this behaviour is completely unacceptable in a certain
context, how hard is it for the programmer to disable it, or to work
around it?".

If you were to forcibly enable echoing on stdin, how hard would it be
for the programmer to restore the terminal driver to its original
state? AFAICT, it's impossible; the original state simply wouldn't be
available. In such a situation, the only option available to the
programmer is to not use Haskell.

Part of the reason for C's popularity is that it lets the programmer
take care of the details, rather than being stuck with the language
developer's idea of "the right thing". IOW, there is a complete
absence of problems for which the only solution is "don't use C".

> If people open other terminal devices they are
> much more likely to know what they are doing.  It would be reasonable to
> pin down what happens in that case, but I'm desperately afraid of
> opening Pandora's box when I have to deliver the final bits to CUP in a
> couple of weeks.  So, stdin only for now. 
> 
> | 3. In general, "magic" behaviour (e.g. clearing the ICANON flag when
> | disabling buffering) should at least be documented, otherwise it's
> | likely to confuse experienced programmers. 
> 
> Well I have never heard of the ICANON flag!  I don't expect to put it in
> the Haskell report unless someone tells me it's absolutely unavoidable!

You don't necessarily have to mention the details, just point out that
hSetBuffering may change the terminal driver's settings.

Because it looks so similar to ANSI C's setvbuf(), someone who is
migrating from C to Haskell may assume that it's roughly equivalent
(i.e. that it only affects the user-space stream, and not the
underlying OS descriptor).

-- 
Glynn Clements <glynn.clements@virgin.net>