Haskell 98: Behaviour of hClose

[Simon Peyton-Jones]

Glynn

Thanks for your input.  If you think it is important, could you please
propose one or more concrete changes to the wording of the Language
Report or the Library Report or both.  Then we'll get a better idea of
what you have in mind.   (Start from the current draft at
http://research.microsoft.com/~simonpj/haskell98-revised)

The H98 report is deficient in many respects.   It's been improved
steadily over the last three years, but still has gaps.  This may be one
of them.  But since the report is about to go over the wall to CUP and
get printed as a book (end of Sept) the overriding priority is not to
introduce new errors and accidentally make things worse.  With that in
mind, I think we can only add a sentence here and there to clarify,
nothing big.

Simon

| -----Original Message-----
| From: Glynn Clements [mailto:glynn.clements@virgin.net]
| Sent: 18 September 2002 20:50
| To: Simon Peyton-Jones
| Cc: haskell@haskell.org
| Subject: RE: Haskell 98: Behaviour of hClose
|=20
|=20
| Simon Peyton-Jones wrote:
|=20
|=20
| > | 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.
|=20
| Argh. Too much of this and you end up with a language which isn't
| suitable for anything other than "simple stupid programs".
|=20
| 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?".
|=20
| 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.
|=20
| 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".
|=20
| > 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!
|=20
| You don't necessarily have to mention the details, just point out that
| hSetBuffering may change the terminal driver's settings.
|=20
| 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).
|=20
| --
| Glynn Clements <glynn.clements@virgin.net>