[antlr-interest] Upgrading ANTLR (v2 -> v3)

Ian Kaplan iank at bearcave.com
Tue Sep 2 19:28:02 PDT 2008


> Is there any way to swag an estimate for v2 --> v3 conversion of an
> existing ANTLR pipeline targetting C++ code?  I could just say "two months",
> but that is usually wrong.
>

  I agree with Gavin Lambert's comment: it depends (there, see I'm entirely
safe in what I say).

  I have been working on a query language for a graph database (that is, a
database that stores large semantic graphs).  This is not, by the way, the
horrid SPARQL, but a language that has been developed at Lawrence
Livermore.  The ANTLR dot-g file is about 1,500 lines of grammar, comments
and Java code.  The Java code builds objects that mirror the query
language.  The language doesn't need an abstract syntax tree, in my view.

  It took me about three weeks to convert the parser from ANTLR 2.7 to ANTLR
3.1.  Most of this involved rewriting almost all of the Java code associated
with the grammar rules.

  As you may have noted, I whined and bitched about the problems I was
having (suffering in silence has never been one of my virtues).  But there
we two advantages I got from moving to ANTLR 3.1.  Perhaps the major
advantage is that this is where ANTLR development has gone.  So if the
software is to move forward, in the long run there isn't much choice.  The
other advantage was the backtracking parser.  It was great to be able to
just define a language and modify it without worrying about how it could be
expressed in an LL(2) grammar.  As it turned out, there was one part of the
language where ANTLR generated a syntactic predicate.  As far as I can tell,
it doesn't do much back tracking in other parts of the language.

  I did find that that ANTLR web site down played the difficulty of moving
from ANTLR 2.7 to 3.1.  This is because it dealt mainly with the changes in
the grammar.  But ANTLR 3.1 forced me to make a lot of changes in the Java
code associated with the rules.  The ANTLR community is pretty heavily
focused on Java.  So things may be even more difficult in the C/C++ realm,
especially since there is only a C runtime.  If possible it might be worth
considering a Java parser and support code.  I realize that this will not
work if the rest of the code base is C++.  But the performance advantage of
C++ is a lot less than it used to be.

  Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080902/3e13c73e/attachment.html 


More information about the antlr-interest mailing list