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>