Layout parsing

[Frederik Hanghøj Iversen]

I have a few questions regarding the "Layout syntax" feature of bnfc.

1. Is it possible to tell bnfc to use other delimiters than ";", "{" and "}".

2. The layout mechanism must be triggered by a *token* rather than a production rule. This seems a bit counter-intuitive to me, but I suspect there is a technical reason for this, because as the documentation mentions the layout mechanism lies between the lexer and the parser. The reason I find it counter-intuitive is perhaps best explained with an example. Consider this contrived example:

    n : a
      -> a
      -> List a
    n a0 a1 = a0 : a1 : nil

     

Here ":" is overloaded and in this (granted not the best example) we could imagine that we only want the type declaration to introduce a layout rule. Formulated as a question: Is it possible to associate layout rules with production rules? I suspect the answer is no.

3. And lastly, it seems that the layout rules must always introduce a list of expressions. Is it possible to in stead expect a single expression? Let me illustrate with an example. Imagine we wanted to write some kind of "lisp without all the parenthesis":

    a =
      b = c
          d
      e = f

Say we wanted to have this parse as:

    (a
      (b (c d)
      (e f)))

Rather than:

    (a
      (b (c) (d)
      (e f)))

Notice the subtle difference where c d is an application rather than a list of expressions.

--

Regards

Frederik Hanghøj Iversen

[Andreas Abel]

Hi Frederik,

hope you are well!

On 2020-04-26 14:00, Frederik Hanghøj Iversen wrote:
> I have a few questions regarding the "Layout syntax" feature of bnfc.
>
> 1. Is it possible to tell bnfc to use other delimiters than ";", "{" and
> "}".

Currently not. Currently, the layout feature is no more than a proof of
concept.

> 2. The layout mechanism must be triggered by a *token* rather than a
> production rule. This seems a bit counter-intuitive to me, but I suspect
> there is a technical reason for this, because as the documentation
> mentions the layout mechanism lies between the lexer and the parser.

Yes, the layout mechanism inserts braces and semicolons into the token
stream.

> The reason I find it counter-intuitive is perhaps best explained with an
> example. Consider this contrived example:
>
>     n : a
>       -> a
>       -> List a
>     n a0 a1 = a0 : a1 : nil
> Here ":" is overloaded and in this (granted not the best example) we
> could imagine that we only want the type declaration to introduce a
> layout rule. Formulated as a question: Is it possible to associate
> layout rules with production rules? I suspect the answer is no.

No, see above. Layout is handled before we come to the parsing.

> 3. And lastly, it seems that the layout rules must always introduce a
> list of expressions. Is it possible to in stead expect a single
> expression? Let me illustrate with an example. Imagine we wanted to
> write some kind of "lisp without all the parenthesis":
>
>     a =
>       b = c
>           d
>       e = f
>
> Say we wanted to have this parse as:
>
>     (a
>       (b (c d)
>       (e f)))
>
> Rather than:
>
>     (a
>       (b (c) (d)
>       (e f)))
>
> Notice the subtle difference where c d is an application rather than a
> list of expressions.

It seems that "=" is your application operator, placed after the
function part. Wouldn't you have to write

a =
b =
c = d
e = f

or similar to get what you want? I do not see why the stuff after "b ="
should get a different interpretation than the stuff after "a =". Note
that a newline is not needed to trigger the beginning of a layout block.

Cheers,
Andreas