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 <lexi.lam...@gmail.com> wrote: > 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 >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
