Re: Tab "\t" character behaviour in (Win)hugs/ghc
Rijk-Jan van Haaftenrjchaaft@cs.uu.nl writes:
Recently, Craig Delehanty discovered that there is a difference in behaviour of putStr "a\tb" between Hugs and WinHugs (see comp.lang.functional).
Hugs interprets it as a alignment character:
putStr "a\tb" "a b"
(7 spaces) but in WinHugs, it is always the same as 8 spaces:
putStr "a\tb" "a b"
(8 spaces)
What does the language definition say about this?
Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters. So, WinHugs is being unnecessarily non-standard to interpret "\t" as being a shorthand for 8 spaces. I've changed this to have it fall into line with the conventional interpretation & checked in the tweak. Thanks for reporting this. --sigbjorn
Sigbjorn Finne wrote:
What does the language definition say about this?
Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters.
Actually, Appendix B3 of the Haskell 98 Report says The "indentation" of a lexeme is the column number indicating the start of that lexeme; the indentation of a line is the indentation of its leftmost lexeme. To determine the column number, assume a fixed-width font with this tab convention: tab stops are 8 characters apart, and a tab character causes the insertion of enough spaces to align the current position with the next tab stop. For the purposes of the layout rule, Unicode characters in a source program are considered to be of the same, fixed, width as an ASCII character. The first column is designated column 1, not 0. --brian
Brian Boutel wrote:
Sigbjorn Finne wrote:
What does the language definition say about this?
Nothing at all, I believe, but the convention is for tab characters to be interpreted by an output device as moving the cursor to the next tab stop/alignment column. In the absence of any custom set of tab stops, the convention is to space them evenly every 8 characters.
Actually, Appendix B3 of the Haskell 98 Report says
The "indentation" of a lexeme is the column number indicating the start of that lexeme; the indentation of a line is the indentation of its leftmost lexeme. To determine the column number, assume a fixed-width font with this tab convention: tab stops are 8 characters apart, and a tab character causes the insertion of enough spaces to align the current position with the next tab stop. For the purposes of the layout rule, Unicode characters in a source program are considered to be of the same, fixed, width as an ASCII character. The first column is designated column 1, not 0.
Yes, tabs are defined for Haskell source, but not for output of a Haskell program. -- Lennart
"Brian Boutel" <brian@nzcs.org.nz> writes:
Sigbjorn Finne wrote:
What does the language definition say about this?
Nothing at all, I believe, but [...]
Actually, Appendix B3 of the Haskell 98 Report says
[....] That deals with Haskell lexical syntax, and not the interpretation of \t during IO. --sigbjorn
"Rijk-Jan van Haaften" <rjchaaft@cs.uu.nl>:
What does the language definition say about [tabs]?
Sigbjorn:
Nothing at all, I believe, but the convention is [...]
The Haskell 1.4 report says what is meant to happen (section 1.5) (which was to follow the convention). The Haskell 98 report omits this section. I would like to report this omission as a bug in the report. [I think this is a different bug from the "how do Bird tracks affect layout?" bug reported by Malcolm Wallace earlier today.] -- Alastair Reid reid@cs.utah.edu http://www.cs.utah.edu/~reid/
Alastair David Reid wrote:
[...]
What does the language definition say about [tabs]? [...] The Haskell 1.4 report says what is meant to happen (section 1.5) (which was to follow the convention).
The Haskell 98 report omits this section.
I would like to report this omission as a bug in the report.
I don't see this as a bug. I think the convention for outputting a tab character should be just to send a tab character to the output device or file used. In the first case the output device should decide what to do with the tab character. How should the meaning of tabs be specified? Should the report say that outputting a tab means to output some space characters? That would of course force a specific layout but would it make impossible to include tab characters in Haskell-generated files. Outputting tab characters to files should result in tab characters included in the file. Because those characters are interpreted in a system-dependent way if the files are later sent to an output device they should also be interpreted system-dependent if they are written to an output device directly.
[...]
Wolfgang
participants (5)
-
Alastair David Reid -
Brian Boutel -
Lennart Augustsson -
Sigbjorn Finne -
Wolfgang Jeltsch