-
I want to support arbitrary dangling constructs:
There is https://en.wikipedia.org/wiki/Dangling_else#Avoiding_the_conflict_in_LR_parsers This seems a bit complicated because it's not just "expand to something", but we also need to consider the shift-reduce conflicts in the expansion. After some fiddle I realize inorder to support x constructs that has danglings, we need 2^x rules if using the above technique? I've checked some other parsers but hadn't found one that actually solved this rather than walkarounded this. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments
-
It seems like impossible? I'll have to generate a lot of helper types if we have this? |
Beta Was this translation helpful? Give feedback.
-
There's some discussion around it here, although no general purpose solution. I think depending on your use-case you might get around it using conditional macros (which avoid some of the duplication but are unfortunately undocumented currently). You will find an example (although not related to dangling else) of a simple use of conditional macros to avoid code duplication, once again, in the Nickel grammar. I haven't tried myself to tackle the dangling else problem (as Nickel is an expression-oriented functional language, so every |
Beta Was this translation helpful? Give feedback.
There's some discussion around it here, although no general purpose solution. I think depending on your use-case you might get around it using conditional macros (which avoid some of the duplication but are unfortunately undocumented currently).
You will find an example (although not related to dangling else) of a simple use of conditional macros to avoid code duplication, once again, in the Nickel grammar.
I haven't tried myself to tackle the dangling else problem (as Nickel is an expression-oriented functional language, so every
if
must have anelse
), so I can't really help further.