The history here: several people independently noticed that it might be
better to implement the "parse error" part of layout by doing something
simpler than full parsing. For example, if we just count brackets in the
lexer, then we can handle things like
f (case x of y -> z)
and if we treat let/in as a pair of brackets too, then the common case of
let x = y in z
also works. The AlternativeLayoutRule was Ian's implementation of this
idea, and (if I remember correctly) contains a number of fixes that arose
from discovering interesting cases of code in the wild that weren't handled
by the obvious bracket-matching techniques.
My conclusion from this experiment - which is a bit subjective and might
differ from others - is that
* you need a lot of special cases to handle code that Haskell users expect
to parse
* and then the specification becomes pretty complex, and hard to explain to
someone
So ultimately it didn't solve the problem in a nice way, unfortunately. The
"parse error" rule is hard for implementers, but it's not actually that
hard for users.
If other people agree with this conclusion, we should kill off the ALR code
now.
Someone is going to ask me for examples of those "special cases", I'm
afraid I don't remember - I only cached the answer to the question, not the
working :) You'd probably have to go digging through the ALR code.
Cheers
Simon
On Tue, 6 Apr 2021 at 01:36, Alexis King
On 4/5/21 2:36 PM, Ian Lynagh wrote:
It was originally designed by John Meacham: https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html
Thanks, Ian—I had stumbled across a link to the old Haskell Prime trac wiki while I was searching for information, but I didn’t realize where it had been migrated to.
It isn't exactly equivalent to the Haskell layout rule, but it's fairly close and much simpler (due to not having the "on a parse error" case).
Yes, I gathered as much from the implementation. The idea makes sense, but of course it doesn’t provide much benefit to have a simpler implementation unless it actually *replaces* the “on parse error” approach.
Given this appears to be a long-defunct proposal, a natural followup question is to ask whether there’s any reason this code is still in GHC. Is it used for any purpose, or could it be removed?
Alexis _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs