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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe

Reply via email to