RE: Haskell 98: Behaviour of hClose
| No yelling, but some random points for consideration: | | 1. It might be worth being more explicit, i.e. stating whether this is | because the runtime explicitly enables echoing, or because it's | assumed that echoing will already be enabled. Well, at Haskell user doesn't care. It's precisely because we want to specify the behaviour of Haskell programs, regardless of the underlying OS, that it's worth trying to nail down these things. If the Haskell RTS has to nudge the OS into echoing, that's what it should do. This only applies the default settings. (You can change echoing settings via the IO.hSetEcho etc.) | 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. 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! Simon
"Simon Peyton-Jones" <simonpj@microsoft.com> writes:
(You can change echoing settings via the IO.hSetEcho etc.)
Ahem, one of the deficiencies of Haskell'98 is that there is no function IO.hSetEcho. There used to be one in Haskell 1.3 I think, so I guess there was a good reason for removing it? Regards, Malcolm
On Wed, Sep 18, 2002 at 09:21:02AM +0100, Simon Peyton-Jones wrote:
| No yelling, but some random points for consideration: | | 1. It might be worth being more explicit, i.e. stating whether this is | because the runtime explicitly enables echoing, or because it's | assumed that echoing will already be enabled.
Well, a Haskell user doesn't care. It's precisely because we want to specify the behaviour of Haskell programs, regardless of the underlying OS, that it's worth trying to nail down these things. If the Haskell RTS has to nudge the OS into echoing, that's what it should do.
I'm not sure about that. If I turn off echoing in the OS and then run a Haskell program, I expect that it won't echo. Echoing is a function of the environment. If a Haskell implementation messes with the terminal settings for some reason (as Hugs does) then it should emulate the original settings, but that's all. So I favour deletion of the offending sentence, leaving this as an environment-dependency.
Ross Paterson <ross@soi.city.ac.uk> writes:
So I favour deletion of the offending sentence, leaving this as an environment-dependency.
I second that. I came to Haskell after many other programming languages, and was VERY surprised by echo behaviour. I vote for consistency with long-standing standards (C library, every other language) and versatility (echo and buffering determined by environment -- it should be configured to also run non-Haskell programs, after all). Feri.
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>
participants (5)
-
Ferenc Wagner -
Glynn Clements -
Malcolm Wallace -
Ross Paterson -
Simon Peyton-Jones