bert.verhees at rosa.nl
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