[antlr-interest] A postmortem of my use of antler
siemsen at ucar.edu
siemsen at ucar.edu
Tue Mar 11 14:10:56 PDT 2008
On Mar 11, 2008, at 1:02 PM, Andy Tripp wrote:
> Richard Clark wrote:
>>
>> Andy Tripp <antlr at jazillian.com> wrote:
>>
>>> I really don't like the book example of evaluating an expression
>>> with
>>> ANTLR. Better to build an AST as one step, and then evaluate the
>>> expression by walking the AST as a distinct step.
>> Except that evaluate-and-do is a common (and powerful) design pattern
>> with ANTLR. Working via an AST is other powerful design pattern. They
>> both have their uses; knowing when to use which is a key skill for
>> mastering ANTLR.
> IMO, "evaulate-and-do" has no reasonable uses. You may call it a
> "design pattern", but
> that doesn't make it a good one.
>> Folks who have taken a compiler class tend to prefer ASTs because
>> they
>> fit what a compiler does (parse, transform, emit.) Emitting an AST is
>> also great for taking multiple variations on a phrase and reducing it
>> into a standard expression before emitting a value or performing an
>> action.
> Yes, ASTs are great for lots of things. But what is "evaluate-as-
> you-parse" good for, other
> than teaching you how to "evaluate-as-you-parse"?
Wow, I think this question is backwards. I learned ANTLR from the
book as I wrote
a nontrivial translator. I developed it using the time-honored
tradition of adding only
what was needed. An AST never was, so my translator never grew an
AST. Yet it
does the job very well. To me, evaluate-as-you-parse is the normal
case, and the
question is "what are ASTs good for, other than speeding things up if
you need
multiple passes?".
There are many languages (most?) that can be translated without an
AST phase.
If I don't need one, why bother? Perhaps ASTs add some nice
modularity, or
compartmentalize semantic errors or something? I'm ready to be
convinced, but I
want some value to compensate for the complexity they add to the
translation process.
I took a compiler class at the university many years ago. We used
yacc/lex and the
famous Aho/Ullman dragon book. I agree with a previous post, lexing/
parsing is
*hard* to do well. Now I'm done with the theory, and I just want to
get the job done.
IMHO, ANTLR is the next generation of yacc/lex, and is a great leap
forward. Many
thanks to Terence for encapsulating the concepts in code so well.
Again, I'm done with
the theory, so if Terence were to proclaimed "ASTs are good, you
should always use
them" I wouldn't argue, I'd just do it.
I disagree with the original posting - using ANTLR is far superior to
hand-coding a
parser, which I've done. I agree that the non-book documentation
isn't great, but the
simple solution is "get the book". Even with the book, questions
like "should I
use an AST or not" make learning hard on newbies. Some of us still
haven't figured
that one out :-)
-- Pete
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20080311/4dd64c25/attachment.html
More information about the antlr-interest
mailing list