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

Add harmonized jtb #59

Closed adMartem closed 1 year ago

adMartem commented 1 year ago

This includes previous PR changes and additional ones to add two new experimental options: X-SYNTHETIC_NODES_ENABLED, which enables the automatic generation of syntactic nodes when required by the @lhs = (...) syntax and/or JTB-compatible trees, and X_JTB_PARSE_TREE, which enables the generation of JTB visitor-compatible trees. Note that the behavior of the @lhs = ... is enhanced to not require an explicit injection of the property(s) (they are automatically performed). Given the ability to inject properties automatically into the optional synthetic (and thereby anonymous) nodes, it seems silly to require the user to manually include an INJECT directive and redundant property declarations when we could do it for them.

adMartem commented 1 year ago

The more I think about it, especially with these changes, I tend to believe I should make the changes to python and csharp to implement all of these new options, including JTB, even though JTB behavior is probably only useful for the Java generation, since there is no legacy reason to use JTB for other than Java and, IMO, the JTB parser/visitor model is inferior to the standard CongoCC model with its extensions. But by supporting exactly the same behavior, I think it makes all three much easier to keep in sync. And, who knows, there could be a super important JTB project out there that is about to discover CongoCC. This is after a week of hair pulling to get all 3 in sync and structured the same way.

adMartem commented 1 year ago

This in now functionally complete in all three languages. Note that the JTB option provides everything except the actual Node subclasses that are generated. In the COBOL case, they are defined in the grammar.ccc and subclassed accordingly. One open question is whether we want to leave it like this (and maybe provide a JTB-based example that can serve a template for anyone making the migration from JTB to CongoCC), or do we want to have the option cause the generation of the syntax node classes and their respective JTB superclasses. Also, the LHS+ feature and the JTB have only been tested so far with Java. Once we are satisfied and these are merged, I will provide an example that will serve also to test these. I can test Python and Java with the COBOL grammar (a pretty thorough test), but I haven't been able to set up a CSharp environment here (that works).

adMartem commented 1 year ago

Also note there are several places in the CSharp and Python versions of ParserProductions.inc.ftl with an "OMITTED" note. I added that where I found differences between them and the Java template. I wasn't sure if it was on purpose, or just reflected the lack of synchronization between the language variants.

adMartem commented 1 year ago

I notice that the BASE_NODE_CLASS is apparently not imported into the generated parser. That needs to be fixed in order for the synthetic nodes to be defined (the are of the BASE_NODE_CLASS when not in JTB mode).