<div dir="ltr">Hi Alexis,<div><br></div><div>I wasn't sure what the "alternative layout" is either and did some googling, and it appears that it is something that was never really documented properly.   The following link contains pointers to the commit that introduced it (in 2009!)  (not the main ticket but some of the comments)</div><div><br></div><div><a href="https://ghc-tickets.haskell.narkive.com/htgwkF80/13087-alternativelayoutrule-breaks-lambdacase">https://ghc-tickets.haskell.narkive.com/htgwkF80/13087-alternativelayoutrule-breaks-lambdacase</a><br></div><div><br></div><div>Overall, I do think that Haskell's layout rule is more complicated than it needs to be, and this is mostly because of the rule that requires the insertion of a "virtual close curly" on a parse error.  This means that the parser and lexer have to communicate.  I've implemented a few languages with layout, and usually use a simpler version of layout that just omits that case.  The benefit is that layout can be implemented as a simple pre-processor pass on the stream of tokens,  which is much simpler to specify and implement.   The drawback is that sometimes you have to write programs in a slightly different way, but nothing that can't be easily worked around.</div><div><br></div><div>My feeling is that it'd be pretty tricky to do layout in the parser with grammar rules, but you may be able to do something with the parser state.   I wonder how different it would end up looking though, as in a way that's exactly what we are doing now, it is just that some of the state is the lexer.</div><div><br></div><div>-Iavor</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 3, 2021 at 5:05 PM 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>
    <p>Hi all,</p>
    <p>I’m wondering if there are any resources that discuss the design
      of GHC’s implementation of layout. (I haven’t been able to find
      any.) From looking at the code, here’s what I’ve gathered so far:</p>
    <ul>
      <li>Layout is implemented in the lexer
        (compiler/GHC/Parser/Lexer.x).<br>
        <br>
      </li>
      <li>The implementation is similar in some respects to the approach
        described in the Haskell Report, but still fairly different.
        Virtual braces and semicolons are inserted during the lexing
        process itself with the assistance of Alex lexer states (aka
        “start codes”).<br>
        <br>
      </li>
      <li>In order to handle particularly tricky cases like<br>
        <br>
        <pre>    if e then do x; y else z</pre>
        <br>
        where the virtual close brace must be inserted in the middle of
        a line, tokens such as <tt>in</tt> and <tt>else</tt> are given
        special context-sensitive treatment. This appears to be quite
        subtle.</li>
    </ul>
    <p>Overall, I can mostly follow the code, but I still have a few
      unanswered questions:</p>
    <ul>
      <li>The layout-related code consistently uses the phrase
        “alternative layout rule”—what does “alternative” mean here?
        Does it refer to GHC’s implementation of layout? Or maybe it
        refers to <tt>NondecreasingIndentation</tt>? It isn’t clear.<br>
        <br>
      </li>
      <li>The implementation of layout seems quite complex, in large
        part because it has to worry about parsing concerns in the lexer
        in order to handle tricky cases like the one I provided above.
        Is there are reason all this is done in the lexer, rather than
        deferring some more of the work to the parser?</li>
    </ul>
    <p>I’ve found remarkably little information about implementing
      layout in general, so perhaps I’m missing some resources or
      keywords to search for, but any information or perspectives would
      be appreciated!</p>
    <p>Thanks,<br>
      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>