With the following fairly simple grammar:

module mylang
imports Common
context-free start-symbols Start
context-free sorts Start LineSeq Line Ex
context-free syntax
  Start.TopLevel   = LineSeq
  
  LineSeq          = <<ln:Ex>> {layout(offside ln)} 
  LineSeq.Sequence = sq:Ex+    {layout(align-list sq)}

  Ex+ = Ex+ ln:Ex {layout(offside ln)}
  
  Ex.Int      = INT
  Ex.Sum      = <<Ex> + <Ex>> {left}
  Ex          = <(<Ex>)> {bracket}

context-free priorities
  LineSeq.Sequence <0> .> Ex+ = Ex
  Ex+ = Ex <0>         .> LineSeq.Sequence,
  Ex+ = Ex+ Ex <1>     .> LineSeq.Sequence

and with the jsglr-version: layout-sensitive parameter set for sdf3 in metaborg.yaml, Spoofax is able to build mylang and unambiguously parse e.g.

  99
    + 88
  77
  66

(note two leading spaces on all lines except for the second, which has four). Similarly if the number of leading spaces on the second line is reduced to two or fewer, the parse fails.

However, in the failing parse case, there are two points that make use of the editor on “mylang” files somewhat confusing:

1. The parse error is reported on the third line, not the second, even if it is the second line where the indentation is out of whack. In general, it seems that layout errors are always reported on the subsequent line, or reported as “Unexpected end of input” if they occur in the final line.

2. The error message for layout problems is merely “Unexpected input” or “Unexpected end of input”, which could make it a bit hard to know what the problem is.

While neither of these is a show-stopper, the ease of use of languages with layout rules would be improved by better error reporting here.

Submitted by Glen Whitney on 1 February 2021 at 19:27

The error tag may be a bit severe here, but I didn’t see a way to change the tag.

Thank you for reporting this. The jsglr-version: layout-sensitive parser currently does not support error recovery. Therefore, the parser only reports the “Unexpected input” or “Unexpected end of input” messages, depending on whether it failed halfway or at the end of a file. While the jsglr-version: v1 and jsglr-version: recovery parser variants do support error recovery (resulting into better error messages), it is an open issue to combine this with layout-sensitive parsing. Although we are working on combining parser variants, don’t expect the combination of error recovery and layout-sensitive parsing soon.