AQL ANTLR4-grammar

Bert Verhees bert.verhees at
Mon Aug 24 13:00:52 EDT 2015

On 24-08-15 15:36, Thomas Beale wrote:
> but it's more concise for the production rules, and as you say, it 
> works for any output side. So that's a big win. Over time, I expect 
> we'll cnvert everything to Antlr4. 
To say that, have you ever seen code generated by yacc/lex, bison or JJ. 
It is unreadable, and impossible for a normal human being to debug.
I removed one or two little bugs in the ADL-parser generated by JJ 
(regarding to some 13606 keywords).
I also once had to find a bug in some Bison generated C code. I still 
get said as I think back to those days.

It gave in both occasions a very unpleasant feeling of uncertainty, 
because, one can see at some parts what a small change causes, but how 
can one ever be sure that nothing unexpected changed in those hundreds 
of regenerated functions with only a cryptic name. You need to run your 
many junit-tests and still you will not be sure.

What those parsers/generators do is very severe cursing against every 
good programming practice.

How different is that in Antlr4.5, where there is a clean pattern of 
visitor or listener classes, which will handle your purposes.

It is not without reason that the JVM compiler makes no use of any 
generated code at all. Every parsing routine is written by hand.
That is the other way to do it, and can only be done by a large team.
But, what you see, if you look at Javac, it is all neat and 
understandable code with visitors handling everything.

And that is exactly the same thing Antlr does, but not by writing by 
hand, but generating.
It would not surprise me if the next Javac would use Antlr for code-parsing.

I regard Antlr4.5 as a big step in software development, causing complex 
grammar much easier to handle and to understand.

I will welcome very much if the OpenEHR community will have all parsable 
code done with Antlr grammars. I think it is necessary to maintain a 
good quality standard.

So, was I convincing?


Have a nice day

More information about the openEHR-technical mailing list