Jon Fairbairn wrote [snip]

Well, there's two things to consider: Haskell 98, which probably shouldn't change, and extended Haskell, which probably should. Especially if we can make the rules both simpler and better. [snip] How can I resist? I proposed the following revised layout rule some time ago in a message to the Twa Simons. Note that unlike the standard Haskell layout rules it does not need to read the parser's mind. Of course the problem is that while it should work fine for the way I lay out Haskell, it might not work for other people.

We represent the lines in a file in a tree like structure: data Grouped line = Grouped line [Grouped line] The meaning of Grouped A lines is a line A, followed by a list of groups, each beginning at the same deeper ind entation. So for example A B C D would go to something like Grouped A [Grouped B [Grouped C []],Grouped D []] In the code I've written A B C produces an error message, but on second thoughts I think the best behaviour wou ld be to treat it like A ++ B C though it's too late to code that now . . . The layout processor would group the lines according to this algorithm. It woul d then output the result of the grouping. When it came to Grouped first rest it would determine if the last token of first is "do", "of", "where" or "let", and rest does _not_ begin with a "{" token. If both these conditions were satis fied, it would output "{" before, ";" inbetween elements, and "}" after when outputting t he "rest" list. This seems to me to solve most of the fundamental problems, and be somewhat more intuitive than the existing algorithm. It would behave differently in that do if test then do act1 act2 else do act3 act4 is legal. But it would also be necessary to alter the context-free-syntax so th at (1) the contents of the module were not separated by ";"'s, but by each being a single item in the [Grouped line] list. (The old where {decl1 ; decl2 ; . . . ; decln} syntax would probably have to remain, for compatibility reasons). (2) single-line forms without braces, like "let a = 5 in a+a" work. This is only a first approximation, in that do if test then do act1 act2 else do act3 act4 isn't legal. Perhaps one way of fixing this is to modify the layout algorithm s o that tokens such as "then", "else", "in" and ")" before which a semicolon can't make any sense anyway, get tagged onto the previous group if that began at the same column as t hey did. I don't claim this as the perfect solution. But since layout is something which is rather confusing and at the moment seems to have distinctly rough edges, it might be wo rthwhile experimenting with something like this, to see how much code it would break

I wrote:

...

Can someone remind me why the "A close brace is also inserted whenever the syntactic category containing the layout list ends" part of the rule is there?

Lennart wrote:

It's so you can write let x = 2+2 in x*x (and similar things)

and Arjan van IJzendoorn wrote:

x = (3, case True of True -> 4)

The ')' ends the syntactic category 'tuple'

So we get all this misery just so that people can cram things onto fewer lines?

let x = 2+2 in x*x

could be

let {x = 2+2} in x*x

or

let x = 2+2 in x*x

and

x = (3, case True of True -> 4 )

would be fine. I'd like to see a "-fuse-simpler-layout-rule"¹ option on the compilers. . . Jón 1. Why "-f" anyway? It took me ages to work out what "-fallow-overlapping-instances" meant -- I wondered how "fallow" could apply to overlapping instances. -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk 31 Chalmers Road jf@cl.cam.ac.uk Cambridge CB1 3SZ +44 1223 570179 (after 14:00 only, please!)