| In 7.1, the Report says of getChar, getContents and friends: | | "By default, these input functions echo to standard output." | | This would mean that the example given: | | main = interact (filter isAscii) | | would print the input with all ASCII characters duplicated. | | Surely it should say that if the standard input is a terminal device the | input is echoed on that device. Or maybe the sentence should be deleted. Ross's speaks truth. In fact, the overall behaviour of a Haskell program when used from a terminal ought to be predicable regardless of OS. And indeed one expects the behaviour to differ depending on whether stdin is a terminal or a file. So I propose to adopt Ross's modification: "Surely it should say that if the standard input is a terminal device the input is echoed on that device." This describes what Haskell implementations actually do, and it describes the desired behaviour. All this is about the Language Report. In the Library Report, it says that "getLine" is sort for "hGetLine stdin". So that implies that If the standard input (stdin) is a terminal device, any input on stdin is echoed on that device So, for consistency, I propose to add that to the IO chapter of the library report. Does that seem right? It is very late in the day to be fiddling with the Report. I'll emit an update in a separate message. Simon
Simon Peyton-Jones wrote:
| In 7.1, the Report says of getChar, getContents and friends: | | "By default, these input functions echo to standard output." | | This would mean that the example given: | | main = interact (filter isAscii) | | would print the input with all ASCII characters duplicated. | | Surely it should say that if the standard input is a terminal device the | input is echoed on that device. Or maybe the sentence should be deleted.
Ross's speaks truth. In fact, the overall behaviour of a Haskell program when used from a terminal ought to be predicable regardless of OS. And indeed one expects the behaviour to differ depending on whether stdin is a terminal or a file.
So I propose to adopt Ross's modification: "Surely it should say that if the standard input is a terminal device the input is echoed on that device." This describes what Haskell implementations actually do, and it describes the desired behaviour.
All this is about the Language Report. In the Library Report, it says that "getLine" is sort for "hGetLine stdin". So that implies that
If the standard input (stdin) is a terminal device, any input on stdin is echoed on that device
So, for consistency, I propose to add that to the IO chapter of the library report.
Does that seem right?
No. A terminal device may echo or it may not. Even if the run-time explicitly enables echoing, there is no guarantee that it won't subsequently be disabled. Certainly, the existing statement is wrong, though. -- Glynn Clements <glynn.clements@virgin.net>
(This is mostly a summary of discussions taking place on the i18n list. Some things have come up that might impact the Report, and I'm not sure if it has propagated to the right places) While we're at it, are there any plans to remove this paragraph from section 2.1: | Haskell uses a pre-processor to convert non-Unicode character sets | into Unicode. This pre-processor converts all characters to Unicode | and uses the escape sequence \uhhhh, where the "h" are hex digits, | to denote escaped Unicode characters. Since this translation occurs | before the program is compiled, escaped Unicode characters may | appear in identifiers and any other place in the program. Apparently, no compilers implement this, and the backslash introduces quite a bit of syntactic confusion. Besides, four 'h's are not sufficient for all code points. Unicode is already supported in strings with \nnnn, from section 2.6: | Escape characters for the Unicode character set, including control | characters such as \^X, are also provided. Numeric escapes such as | \137 are used to designate the character with decimal representation | 137; octal (e.g. \o137) and hexadecimal (e.g. \x37) representations | are also allowed. Numeric escapes that are out-of-range of the | Unicode standard (16 bits) are an error. Note that the 16-bits remark should probably be removed, Unicode code points extend beyond that nowadays. Also, if a provision is made for escaped Unicode in identifiers, it would be nice if the section on layout (2.7) discouraged layout rules where the indentation level depended on the width of non-space characters. (Ideally, this would result in a compiler warning.) In fact, this might always be useful, since some Unicode characters are defined as double width. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
participants (3)
-
Glynn Clements -
ketil＠ii.uib.no -
Simon Peyton-Jones