Back-references and AST Nodes about pegase

[joshuabowers]

Fair and understandable. I've developed an alternative approach for the use case abstracted above via a visitor, so the need for Nodes in back-references isn't necessary. Thanks for the sanity check.

[strblr]

That's an interesting situation. The thing is that once the left hand side of + is parsed, the only context you have of it is a Node, which can be arbitrarily defined with fields unrelated to your captures, or even unrelated to the parsing for that matter. So there is no way Pegase can tell automatically from which sub-matches the Node was built from, therefor it can't enforce anything for the right hand side of +.

Theoretically it might be possible to extend back references to nodes, but the nodes would lose a lot of flexibility as Pegase would need more predictability about the fields. That's not what abstract syntax trees are for. The abstraction must be user-defined.

Your case can however simply be solved by capturing the two operand's ASTs (or reading $children) and comparing them as you see fit in a semantic action.

Does that answer the question?

PS: By the way, that increases my sentiment that nodes and ASTs shouldn't be part of the core Pegase library, but rather distributed as an addon package with plugin and helper functions, for example in @pegase/node. By being entangled with the core package, it gives off the vibe that there is something more to nodes than just custom objects emitted like any other value. In fact it's nothing more. Pegase is not able to derive any deeper context from them.