Reply To: Investigating moving from antlr2 to antlr4

homepage Forums BridgePoint Development and Integrations Investigating moving from antlr2 to antlr4 Reply To: Investigating moving from antlr2 to antlr4

#5590
nehad
Participant

Here what I know so far.
Antlr – antlr4 at least- uses the input grammar to generate Lexar and Parser, with Listeners that notify user when token is recognized, and rule is parsed.

In pt_antlr, we turned off the generation of antlr parser/lexer, that is why we renamed the grammar file from .g to .bnf (I need to double check on this)

So we use antlr to create abstract syntax tree aka AST, and we modified antlr to create our own AST parser to output SQL that populate the model under als project

This SQL file is input for grammar_enhancer.arc that determine which rules needs validations by ! character (another change from antlr as this character has different purpose in antlr), and emit the rule definitions for each rule with the validation function
invocations invoked as needed.

Another archetype runs, this time to create db with these sql instances and all datatypes needed, these information is written in oal_functions.sql

the grammar enhancer generates oal.g which input to antlr to generate oalParser (this part I do not understand yet, why we make this workaround, and oal.g looks like a java class more than grammar syntax)

oal_lex.g is used by antlr to create oalLexer (the oal_lex.g is not generated file, I do not understand this yet, I was expecting to have single .g file used for both parser and lexer generation)

I still do not know why we made these changes yet, as I do not know what lacks in antlr2 causes this work.

I also do not understand why do we need the oal model, and why we generate sql out of AST

I read that there was intention to support another action language when this work is done, but I do not see still how this helps in that.

Regarding moving to in antlr4, I think we either gonna change it to output SQL that populate the oal model, or we will get rid of that if possible, and rely on the listener/visitor invocations to invoke the validation functions.

But we might have issue if we get rid of SQL part, as oal_validate archetype uses the output files from this process to create oal_validate.java

I will look into the build process, generate.xml file, and the named archetypes above so have better understanding how things work correctly and how they fit together.

If anyone has information helps in this investigation or correct wrong information I mentioned above, that would be wonderful :)

  • This reply was modified 4 years, 4 months ago by nehad.