A suggestion regarding %make node builders about canopy

[jcoglan]

I think this shares some of the problems of #7 in that parsing expressions do not have names. A grammar binds rule names to parsing expressions, which are arbitrarily nested, like expressions in a programming language. The %action syntax is bound to these nested expressions, not to rule names. So parsing expressions and their results are really anonymous, there isn't a "type" that we could track and pass through to these functions.

It is possible in theory for us to assign a "type" to nodes based on the rule where they are initially created, where their parsing expression is. However I think this would end up being more confusing, because referencing conceptually "moves" nodes between rules. Some rules generate one of many different types via a choice like a / b / c -- should the nodes this expression returns retain their original type, or the type of the referencing rule? How should this affect optional nodes, or repeitions?

It would also make grammars harder to refactor; grammar rules are effectively function definitions, and imagine a programming language where every value had the name of the function that generated it attached to it. If you refactored by moving code between functions, or splitting functions into smaller units, you'd need to change how all their values are handled. So adding this "type" information strongly couples the grammar to the program that consumes it, in a way that I believe would cause more hassle than its worth.

In cases like yours, there will usually by logic somewhere that cases about the "type" you've assigned to each ParseNode and cause different behaviour. I think that logic should live in the parser by causing different types of object to be created, and the different behaviours should be attached to those objects -- the parser is the place you make these decisions.

[jcoglan]

As mentioned in #7 (comment) I've added a limited form of rule name capture in order to improve error messages. I am still not sold on adding rule names to parse tree nodes, for the reasons mentioned there and on this thread. I will keep it under review for future releases, however.