<div dir="ltr"><div>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 <br></div><div><br></div><div>   f (case x of y -> z)</div><div><br></div><div>and if we treat let/in as a pair of brackets too, then the common case of</div><div><br></div><div>  let x = y in z</div><div><br></div><div>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.</div><div><br></div><div>My conclusion from this experiment - which is a bit subjective and might differ from others - is that</div><div>* you need a lot of special cases to handle code that Haskell users expect to parse<br></div><div>* and then the specification becomes pretty complex, and hard to explain to someone</div><div><br></div><div>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.</div><div><br></div><div>If other people agree with this conclusion, we should kill off the ALR code now.</div><div><br></div><div>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.<br></div><div><br></div><div>Cheers</div><div>Simon<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 6 Apr 2021 at 01:36, Alexis King <<a href="mailto:lexi.lambda@gmail.com">lexi.lambda@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    <div>On 4/5/21 2:36 PM, Ian Lynagh wrote:<br>
    </div>
    <blockquote type="cite">It was
      originally designed by John Meacham:
<a href="https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule" target="_blank">https://gitlab.haskell.org/haskell/prime/-/wikis/alternative-layout-rule</a>
<a href="https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html" target="_blank">https://www.mail-archive.com/haskell-prime@haskell.org/msg01938.html</a></blockquote>
    <p>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.</p>
    <blockquote type="cite">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).</blockquote>
    <p>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 <i>replaces</i> the “on
      parse error” approach.</p>
    <p>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?</p>
    <p>Alexis<br>
    </p>
  </div>

_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>