BNFC's layout handling does not implement the following clause, taken from the Haskell 98 report:
A close brace is also inserted whenever the syntactic category containing the layout list ends; that is, if an illegal lexeme is encountered at a point where a close brace would be legal, a close brace is inserted.
Consider this small (artificial) expression grammar with a sum construct that can use layout.
This is because the closing brace } is inserted mechanically according to the off-side rule, yet it should be inserted more dynamically by the parser to fix the parse error generated by the end token in line 3. Basically, the closing bracket is not inserted by dedentation but also by parse errors.
A layout stop "end" instruction does not help here, as we then close the layout block too early, before the first end, rather than the second end:
BNFC's layout handling does not implement the following clause, taken from the Haskell 98 report:
Consider this small (artificial) expression grammar with a
sum
construct that can use layout.As BNFC has a workaround for parentheses "(...)", we use "begin ... end" here instead.
This grammar handles e.g.
sum { 1; 2; sum { 3;4;5 } * 6 } * 7
. It fails on:The correct reconstruction of the block would be:
However, he token stream generated by the layout pass does not respect the bracketing
begin ... end
:This is because the closing brace
}
is inserted mechanically according to the off-side rule, yet it should be inserted more dynamically by the parser to fix the parse error generated by theend
token in line 3. Basically, the closing bracket is not inserted by dedentation but also by parse errors.A
layout stop "end"
instruction does not help here, as we then close the layout block too early, before the firstend
, rather than the secondend
: