
Malcolm Wallace wrote:
Brian Hulley wrote:
However I think there is an error in the description of this in section 2.7 of the Haskell98 report, which states:
"If the indentation of the non-brace lexeme immediately following a where, let, do or of is less than or equal to the current indentation level, then instead of starting a layout, an empty list "{}" is inserted, and layout processing occurs for the current level ..."
I dispute the "or equal" in the above statement, since it seems to be clearly in contradiction to what is actually being done.
Section 2.7 does say that it is an informal description, so although it is correct, it is not complete. In the case of the module header, the question is really "what is the current indentation level?" (that we must be strictly greater than). The answer can be found in the formal definition of the layout rule in section 9.3. At the beginning of the module, there is _no_ current indentation level - thus the fourth equation of L applies.
Thanks. However I do think the fact that there is a special case for the module head would merit a mention in section 2.7, because at the moment it's a bit like looking at a stack of chocolate cookies and defining the top one to be vanilla - it works but who'd ever have thought of it for themselves just looking at the visual indentation on the screen? On the subject of 9.3, I'm puzzled by: "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. However, to avoid visual confusion, programmers should avoid writing programs in which the meaning of implicit layout depends on the width of non-space characters." Surely almost all Haskell programs rely on the width of every non-space character to be the same as the width of a space (ie monospaced font where one character == one glyph) as in let a = 3 b = 5 I'd suggest that the word "non-space" should be replaced by "multi-glyph" and perhaps there could be a recommendation to avoid the use of multi-glyph characters in the first place (otherwise an editor would have to be smart enough to maintain the correct multi-glyph spaces in the columns under them...) Regards, Brian.