search

congo-cc / congo-parser-generator

The CongoCC Parser Generator, the Next Generation of JavaCC 21, which in turn was the next generation of JavaCC
https://discuss.congocc.org/
Other
36 stars 11 forks source link

Consider removing named child nodes and node lists entirely (related to #72) #73

Closed adMartem closed 7 months ago

adMartem commented 10 months ago

If #72 is deemed desirable, perhaps we should consider removing support for the /.../ and /[...]/ notation entirely, since the @aNode = ... and @aNodeList += ... serves essentially the same function.

I have mixed feelings about this, as I think there might be good reasons to have this associative value capability in some form. Maybe even associative properties like @myMapProperty/theseNodes/ += ... at some point. If so, then the /theseNodes/ += ... form that is currently supported would be a simplified case where the anonymous associative map is built in to every node (that uses it?) and specific additional ones could be used as well.

On the other hand, it might be a solution looking for a problem. I don't think we should add such a feature without evidence of a real use case and, if we did, we could easily put back the notation (if we take it out now).

adMartem commented 10 months ago

As is the case with #72, I'd be willing to do the work if we decided to remove this.

adMartem commented 10 months ago

After performing the work to change postfix naming to the LHS infix form I'm inclined to say we should leave the named node capability in (in LHS form), as I realized there might be some real value to being able to name the node or nodes without changing the tree structure, as is sometimes required when void and interface productions are used. I think it is particularly the case when adding naming to an existing grammar, rather than implementing the grammar from scratch. Anyway, just my thoughts at this time.

adMartem commented 7 months ago

I'm closing this. I think we should leave the named node options in for now.