bnfc icon indicating copy to clipboard operation
bnfc copied to clipboard

Layout pragmas support

Open gapag opened this issue 9 years ago • 0 comments

Rather than an issue description, this is to start a discussion about a limited feature of BNFC. Forgive me but I have plenty of spare time.

As reported in the LBNF report, there are three pragmas:

layout <list of layout words>
layout stop <list of layout words>
layout toplevel

to have BNFC generate languages that care about layout syntax, as e.g. Haskell and Python. To summarize: -- please confirm whether I am right or wrong!-- the support is based on BNFC detecting some "layout words" which tell BNFC that a layout list is incoming; the underlying implementation has BNFC inserting brackets "{" "}" and semicolons ";" , everything hardwired.

CFtoLayout.hs is a big printout of the algorithm described in the LBNF report (and further summarized above). In its current form it is only available for Haskell and it requires that the language has braces and semicolons.

I understand that there might be thousands of different layout syntaxes but seems to me that the layout syntax concept should be related to the concept of terminator/separator, since it has practical meaning whenever there is a list of entities.

E.g. A where clause in Haskell is a list of equalities. A function body in Python is a list of statements.

I do not think we can aim to a flexible layout syntax definition satisfying all the syntax maniacs, and retain the extreme simplicity of BNFC. Yet in the current form I think the constraints are way too strict. My proposal is to have a modified separator macro separator layout <category> which makes sure that the list [<category>] is nested with respect to the context where it is used.

I currently made some experiments with ANTLR and I believe I can extend LBNF to implement such a layout macro; but I understand that this creates a discrepancy between the way layout syntax is handled by two backends. Therefore I would like to listen your opinion about this topic and my proposal. I will develop the extension in my fork anyway.

gapag avatar Nov 02 '15 11:11 gapag