[antlr-interest] Why cant += be used without an "output=" option (and other Q's)

Thomas Brandon tbrandonau at gmail.com
Sat Feb 16 20:23:59 PST 2008


On Feb 17, 2008 6:25 AM, Benjamin Shropshire
<shro8822 at vandals.uidaho.edu> wrote:
>
> Thomas Brandon wrote:
> > On Feb 16, 2008 12:00 PM, Benjamin Shropshire
> > <shro8822 at vandals.uidaho.edu> wrote:
> >
> >  The fact that this
> > isn't a totally standard way of proceeding doesn't help either. More
> > usually you would output an AST or use templates to generate output so
> > this sort of processing isn't the major focus of ANTLR.
>     That right there is my question: why didn't I find this out in the
> first 5 minutes? First impressions are very important, if you put
> something out and at first it looks like one thing and it turns out it
> isn't, if the user doesn't find this out vary quickly, when they do they
> you will be luck if they don't feel like you tricked them. In my cases,
> I think that many of my issues have come from the fact that I don't
> known what questions to ask. Something isn't working the way I expect
> but I don't even known where the start looking for the solution (in my
> cases I wasted most of a day trying to find a syntax error when the real
> error was a philosophy one.
>
>     Correct me if I'm wrong, but isn't what I'm doing the normal mode of
> approach for building a parser in something like yacc or bison? In my
> limited experience the normal approach has been let the generated parser
> find the pieces and let the user write the code to do something with it,
> in my case I was going to manually build the AST.
>
I'm not that familiar with the specifics of other parser tools. I
think the main difference is the presence of inbuilt AST and
StringTemplate handling. Other tools do not have inbuilt output
support so their output is generic. ANTLR also intends to handle such
generic output. It's not so much that what you want to do is a corner
case in terms of ANTLRs intended usage but that it is a corner case in
its actual usage. Many people would write code to do similar things to
what you are trying to do it just seems (given the lack of attention
to this particular problem in ANTLR) that most have also been using
ANTLRs output support. There has been some discussion of this problem,
it was again reported a few days ago leading to it being fixed in the
latest intermediate build. But it has not come up enough to have been
fixed yet. This is also as ANTLR 3 is still in a relatively early
phase and feature additions and major bugs have taken up much of the
development effort, overshadowing more minor issues such as this.
Given ANTLRs very good inbuilt AST support I can't see many reasons to
not use this if you are building an AST. You can produce any sort of
output tree you want. And can still use custom AST building code with
output=AST. Though ANTLRs tree construction operators and rewrite
rules mean this is rarely difficult.
>      The change I'm hoping for would take about 15-20 minutes by an
> expert in antlr: wright up a "this is how antler is expected to be used"
> paragraph that has all the "differences in approch" that antlr has with
> regards to other ways of building a parser (by-hand, yacc, etc).
> Probubly the hardest part would be figuring out where to put it on the
> website so that it would be found by anyone looking at antlr even if
> they arn't looking for it. I guess it would be a FNAQ page (frequently
> not (but should be) asked questions)
> > If you are
> > dissatisfied with this then perhaps a commercial product would better
> > meet your demands.
> >
> >
> the part I'm dissatisfied with is the front page. As I see it there are
> a few critical pieces of information that need to be added (or be
> obversely linked  from it) these include a 2-3 sentence description of
> what antler expects the user to do ("Antlr is a system for building
> recognizers, token parsers and tree parsers. It is designed to be used
> to build token parsers from language agnostic grammars that are then
> used to feed language specific tree parsers to perform the custom data
> operations. <verbiage about StringTemplate> While it can operate in
> other modes these are what it is intended to do.")
>
Well, it's likely any such description\page would still have given the
impression that ANTLR was suitable for what you wanted. It is designed
to be it was just the implementation was lagging behind, and the lack
of usage meant this hadn't been as major a concern as such problems in
other areas might have been.
But certainly such a comparison page in the wiki sounds like a good idea.

Tom.
> Sorry about the rambling post:
> Benjamin Shropshire
>
> > Tom.
>
>


More information about the antlr-interest mailing list