Email fail, pardon the noise; original message below.
---------- Forwarded message ---------
From: Jon Purdy
I consider ambiguous grammars a serious usability bug.
I agree. I always make a point of telling ‘%expect 0’ to Happy. (“More often than not the grammar you write will have conflicts”? Excuse you!)
The BlockArguments proposal introduced lots of additional ambiguities, and that's the reason why I'm still opposed to it.
I consider BlockArguments a fix for a bug in the Haskell grammar, namely, a redundant production, requiring an unnecessary operator, which causes confusion for some people coming from other languages. In being fixed, however, it exposed other serious grammar issues. So I’d be strongly in favour of fixing those unclear/ambiguous parses by further (incremental) simplification of the grammar. It would be very nice if the extent of lambda/if/&c. were unambiguous, so I think this idea is a step in the right direction. I would also be very pleased if the layout rule were reformulated as a simpler desugaring step, from a token stream annotated with source locations to such a stream with explicit braces and semicolons inserted, rather than being defined in terms of parse errors and papering over edge cases. My ideal would be a simple formal grammar (LALR, PEG, or even operator-precedence) which is machine-validated as unambiguous, with an implementation written by hand to produce nice contextual error messages, which is typed to prove that it accepts the same language as the formal grammar.