Hard cases for "Note 5" in Haskell layout parsing

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

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
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@gmail.com

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
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
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@gmail.com

Does this help? x1 = case do Nothing; Nothing of _ -> () x2 = case do Nothing Nothing of _ -> () In fact in f2 play with all ways of positioning the line "of _ -> ()" to see there is almost no wrong placement! On 2019-03-11 8:56 p.m., Chris Smith 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.
participants (3)
-
Albert Y. C. Lai
-
Brandon Allbery
-
Chris Smith