RE: Haskell 98: Behaviour of hClose
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 | | | 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>
Simon Peyton-Jones wrote:
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)
1. Regarding the echoing issue, I would simply delete the sentence: By default, these input functions echo to standard output. from section 7.1 of the report, as: a) The functions themselves don't do any echoing. The terminal driver may; but if it does, it will do that regardless of whether or not these (or any other) functions are called. b) The terminal driver may do plenty of other things besides echoing. Singling out echoing for mention is rather arbitrary; OTOH, a complete description would occupy a significant amount of space. 2. Regarding the buffering issue, I suggest adding something along the lines of the following to section 11.4.2 of the library report:
For a stream which is associated with a terminal device, setting the mode to no-buffering will also disable any line-buffering which may be performed by the operating system's terminal driver.
Similarly, setting the mode to line-buffering or block-buffering will enable any line-buffering which may be performed by the operating system's terminal driver.
However, it was only when analysing the existing behaviour in order to write that above that I became aware of the second half. This is potentially more problematic than the first half. While there isn't much point disabling buffering at the stream level if it's still being performed by the terminal driver, there *are* reasons why you might wish to enable buffering at the stream level without enabling canonical mode (which is what the terminal driver's "line buffering" actually corresponds to). E.g. in canonical mode, the EOF character (typically Ctrl-D) will result in a read() from the OS-level descriptor indicating EOF. In "raw" mode, the EOF character will be read literally (i.e. '\004' for Ctrl-D). IOW, while canonical mode results in line-buffering, it also has other side-effects. Another consequence, which has just sprung to mind, is that whereas the buffering mode of a stream is strictly user-space, and therefore internal to the program, the terminal driver settings are a property of the device, and will affect other programs which use that device. Example: a Haskell program is run on a terminal for which canonical mode is enabled (which is normally the case), and that program does "hSetBuffering stdin NoBuffering", thereby disabling canonical mode. After the program terminates, canonical mode will still be disabled for that device. Similar issues arise in C, i.e. you need to explicitly restore the terminal settings when the program terminates or is suspended (via SIGTSTP). However, in C, you would have to have explicitly change the terminal settings (with e.g. tcsetattr()), whereas Haskell does this "under the hood". -- Glynn Clements <glynn.clements@virgin.net>
participants (2)
-
Glynn Clements -
Simon Peyton-Jones