[antlr-interest] Question concerning writing a TreeParser rule

[Rob Greene]

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/795fba0c/attachment.html