[Haskell-cafe] Hard cases for "Note 5" in Haskell layout parsing

[Chris Smith]

Thanks for the answer, Brandon.  I don't think either of these is a
counterexample, though.  Both seem to be handled just fine by the ad hoc
rule of breaking layout contexts for Note 5 only when an "in" otherwise
would not match a "let".  Maybe I'm missing something, though, if you're
expecting to fill in the "..." parts in some clever way.  Do you have a
complete example where this wouldn't be enough?

On Mon, Mar 11, 2019 at 9:35 PM Brandon Allbery <allbery.b at gmail.com> wrote:

> Consider the case where someone has done: let x = do ...
>
> There's also the opposite edge case, which people doing one-liners in ghci
> or lambdabot run into fairly often: ... do ...; let x = 5; ...
> Where the semicolon continues the let bindings, not the do; you must use
> braces to disambiguate.
>
> On Mon, Mar 11, 2019 at 8:56 PM Chris Smith <cdsmith at gmail.com> wrote:
>
>> Quick question.  I'm trying to resolve Haskell layout in order to provide
>> better syntax highlighting, but without committing to building a full
>> Haskell parser.  The reason this is hard at face value is because of the
>> "Note 5" in the relevant part of the Haskell Report, which says that a
>> layout context closes whenever (a) the next token without closing the
>> layout context would not be the start of any valid Haskell syntax, but (b)
>> the current statement followed by an implicit '}' could be valid Haskell
>> syntax.  This rule is why it's okay to write "let x = 5 in x^2", even
>> though let introduces a new layout syntax: the "in" implicitly closes it
>> because "x = 5 in" isn't the start of any valid syntax, so the layout
>> context is implicitly closed before the "in".
>>
>> Now for my question.  Does anyone know other cases besides let/in where
>> this commonly comes up?  Everywhere I've seen this before uses let/in as an
>> example, but then concludes that full parsing is needed and gives up on
>> simpler answers.  But the specific example with let/in is easily handled
>> with a special-purpose rule that closes layout contexts as needed when an
>> "in" keyword shows up.  I cannot seem to construct any other examples,
>> because other layout-introducing keywords have their contents at the end of
>> syntactic element.
>>
>> Is there something I've missed here?  I don't even care if it's a
>> situation where something is technically valid but a horrible edge case.
>> I'm interested in realistic counterexamples.
>>
>> Thanks,
>> Chris
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
>
>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20190312/f54d9912/attachment-0001.html>