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

Benjamin Shropshire shro8822 at vandals.uidaho.edu
Sat Feb 16 11:25:33 PST 2008


Thomas Brandon wrote:
> On Feb 16, 2008 12:00 PM, Benjamin Shropshire
> <shro8822 at vandals.uidaho.edu> wrote:
>   
>> I want to create a grammar that has a repeated term in it:
>>
>> rule : red+;
>>
>> Then I want to add an action to this rule that collects the red's and
>> returns the list of them. Thats shouldn't be to hard:
>>
>> rule returns [IList l ]:  (i += red)+ {$l = $i};
>>
>> but antlr now insistent I add
>>
>> options { output=template; }
>> or
>> options { output=AST; }
>>
>> but both of these are worthless for my needs; 'template' turns i into a
>> list of StringTemplate's and 'AST' try to do something with tree's. What
>> I want is to just get a list of the things that red returns.
>>
>> Is this even possible?
>>
>>     
> This is a bug (or perhaps better an oversight) in ANTLR 3.0.1 that I
> believe has been fixed in the latest intermediate release of ANTLR.
> ANTLR did not allow labels in parsers without an output. I think the
> intermediate builds should be fairly stable as far as basic
> functionality goes and I believe a release is due fairly soon. Or as a
> workaround in the current version you can add output=AST and ignore
> the AST tree, you will be able to access both the returned AST and any
> custom rule returns (use $i.l instead of just $i). Or you could build
> an AST and then have your application deal with this instead of
> directly collecting a list.
>   
>> If it isn't that either antlr has a _serious_ design flaw or it has bean
>> _seriously_ miss-marketed. This operation (parse a tree and give me, the
>> user, unrestricted and direct access to the actual things that was
>> parsed by the referenced rules) is the ONLY thing I was looking for when
>> I found antlr. From a first pass over the documentation I got the
>> impression that it would give me this. From trying to do this, I'm
>> beginnings to fear that it is utterly impossible!
>>
>> Seriously people, you seem to have a major problem. If antlr isn't
>> supposed to do what I'm wanting it to do, why has it taken me 2 weeks to
>> learn this? If antlr can do this, why haven't I yet bean able to figure
>> out how? (I really hope it isn't the other possibility that antlr is
>> just flat broken.)
>>     
> I can't say exactly why it took you so long to get to this point. I
> would imagine a need to familiarise yourself with the more basic
> aspects of ANTLR played some role.

I'm not shure "familiarise" is the correct word; maybe "find" would be 
better (more on that below)

>  The fact that you ran into an issue
> in the current release played a fairly major role.
OK
>  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.

     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.")

Sorry about the rambling post:
Benjamin Shropshire

> Tom.



More information about the antlr-interest mailing list