[antlr-interest] Question concerning writing a TreeParser rule

[Bryan Ewbank]

No, it's not really needed.  The tree is more regular if you always add the
"SEP" parent, which reduces user (i.e., your) errors in later passes.

Sometimes you need to know if it's a single- or a multi-statement block, but
you can always use getNumberOfChildren() to figure that out.

- Bryan

On 4/29/06, Rob Greene <robgreene at gmail.com> wrote:
>
> Talk about timely! I had just gotten a single statement to start
> generating pseudo-code but I couldn't figure out how to take a step back and
> work through a series of program statements. This post clued me in...
>
> I ended up using something slightly different, and I don't see the need
> for the multi switch. I'm wondering if anyone can comment on that? (I always
> assume I'm missing something...)
>
> The core of my grammar looks like this:
> program
>     :    statement (SEP! statement)* { ## = #(#[SEP,"program"], ##); }
> EOF!
>     ;
> statement
>     :    ID EQUALS^ expression
>     |    PRINT^ expression (COMMA! expression)*
>     ;
> expression
>     :    atom ( (PLUS^ | MINUS^) expression )?
>     ;
> atom
>     :    ID
>     |    INT
>     |    LPAREN expression RPAREN
>     ;
>
> My tree parser is like this:
> program
>     : #(SEP (statement)* ) { dump(); }
>     ;
> statement
> {
>     String a,b;
> }
>     : #(EQUALS a=expression b=expression)
>         { addCode("MOV " + a + "," + b); }
>     | #(PRINT a=expression)
>         { addCode("PRINT " + a); }
>     ;
> expression returns [String var]
> {
>     String a,b;
>     var = null;
> }
>     : #(PLUS a=expression b=expression)
>         { var=getTempVar(); addCode("ADD " + var + "," + a + "," + b); }
>     | #(MINUS a=expression b=expression)
>         { var=getTempVar(); addCode("SUB " + var + "," + a + "," + b); }
>     | id:ID
>         { var= getVariable(id.getText()); }
>     | n:INT
>         { var= getConstant(n.getText()); }
>     ;
>
> I'm taking baby steps - and I think I jumped too early the last try!
>
> Question (again): Is the multi switch needed? I don't think so, but
> thought I should ask. This grammar handles multiple statements just fine...
> (ok, I've tested two)
>
> The program rule was what stumped me. It's not like it gets anything
> returned to it (ie, expression returns a variable name in this grammar), so
> I couldn't figure out the tree parser rule until I saw this sample. I needed
> the program rule because I want to dump out psuedo code declaring variables,
> constants, and code once I've gathered all the information.
>
> Thanks!  The whole concept of language design is too cool.  :-)
> -Rob
>
>
> On 4/26/06, Martin Probst <mail at martin-probst.com > wrote:
> >
> > Hi,
> >
> > it's probably going to be easier if you modify your rule like this:
> >
> > batchExprList {
> >    boolean multi = false;
> > }       :
> >         batchExpr (SEP! batchExpr { multi = true; })*
> >         { if (multi) ## = #(#[SEP], ##); }
> >         ;
> >
> > This gives you the follwing tree:
> >                      SEP
> >         /               |               \
> >        ...              ...             ...
> >
> > instead of
> >                 SEP
> >           /              \
> >        SEP        ....
> >    /       \
> > ...     ....
> >
> > This way you can have this tree parser rule:
> >
> > list: #( SEP ( x=expr  { myarraylist.add(x); } )* )
> >
> > Otherwise you'd have to have a member variable for the tree parser
> > (current list root or something), check for it's existence, delete it
> > if necessary etc. - this will make it a lot easier.
> >
> > Martin
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20060429/b3e6bcba/attachment.html