[antlr-interest] Flattening lists?

[Thomas Brandon]

On Sat, Dec 20, 2008 at 7:46 PM, Gary R. Van Sickle
<g.r.vansickle at att.net>wrote:

> > From: Jim Idle
> >
> > On Mon, 2008-12-15 at 08:44 -0600, Gary R. Van Sickle wrote:
> >
> >
> >       Hi all,
> >
> >       Not sure if this is something that should be obvious or
> > not, but is there a
> >       way, completely in ANTLR 3.x (C backend FWIW), to
> > flatten a list of
> >       "things"?  What I mean is, say I have a language I'm
> > trying to parse with
> >       constructs something like this:
> >
> >               // Declare a bunch of variables.
> >               int varA, varB, varC;
> >
> >       Now, it's pretty straightforward to convert this via
> > lexer->parser->tree
> >       parser into:
> >
> >               (VAR_DECL int (INITIALIZER varA) (INITIALIZER
> > varB) (INITIALIZER
> >       varC))
> >
> >       But is there a way to get this instead?:
> >
> >               (VAR_DECL int varA) (VAR_DECL int varB)
> > (VAR_DECL int varC)
> >
> >       Of course once I have the AST I can traverse it with C
> > &&/|| C++, but it
> >       would sure be nice if ANTLR was able to flatten these
> > sort of constructs for
> >       me.
> >
> >       Thanks,
> >
> >
> >
> >
> > rule : INT i+=ID (COMMA i+=ID)  ->^(VAR_DECL INT $i)+
> >   ;
> >
> >
> > Jim
>
> Thanks Jim, but what I'm looking at is a bit more complicated.  What I have
> currently for a parser grammer looks in part like this:
>
>
> [...]
> declaration
>    : ts=type_specifier idl=init_declarator_list ';' -> ^(VAR_DECL $ts $idl)
>    ;
>
> init_declarator_list
>    : init_declarator (',' init_declarator)* -> ^(init_declarator)+
>    ;
>
> init_declarator
>    : declarator ('=' initializer)? -> ^(INITIALIZER declarator
> initializer?)
>    ;
> [...]
>
> (i.e. a slightly simplified version of the C variable declaration syntax)
>
>
> I suppose I could flatten my *grammar* by eliminating the
> init_declarator_list entirely and doing something like this:
>
>
> [...]
> declaration
>    : ts=type_specifier idl+=init_declarator (',' idl+=init_declarator)* ';'
> -> ^(VAR_DECL $ts $idl)+
>    ;
> [...]
>
>
> But this seems like a step backwards, and something that either the rewrite
> rule itself should be able to handle without flattening the grammar, or
> something the tree parser should be able to handle (i.e. match the VAR_DECL
> subtree and then 'iterate' over the children in the init_declarator_list
> and
> taking some action for each one).

You can use rewrite rules but as rewrite rules rewrite the input not the AST
you produce (which in your rules deviates from the desired output) you must
pass the type down to init_declarator_list as a parameter. Like:
declaration
   : ts=type_specifier idl=init_declarator_list[$ts.tree] ';' -> $idl+
   ;

init_declarator_list[Object type]
   : init_declarator (',' init_declarator)* -> ^(VAR_DECL {(Tree)$type}
init_declarator)+
   ;

init_declarator
   : declarator ('=' initializer)? -> declarator initializer?
    ;

(You have to pass an object down as the tree attribute is an object to avoid
an AST dependence and ANTLR incorrectly interprets a parameter of
"(Tree)$ts.tree" as two different parameters, outputting "(Tree),
((Object)ts.tree)", this seems like a bug in ANTLR, thouge perhaps a tough
one to deal with given ANTLR's limited knowledge of the target language).)

Though given the simplicity of the rules it seems simpler to simply collapse
the rules as Jim suggested.
Or you could take the second option you propose and simply handle it in the
tree parser which should also be easy enough.

Tom.

>
>
> Is there really no other way to do this other than flattening the grammar
> itself?  I can especially see that as being unworkable if one's language
> supported "lists of lists" and you wanted to do this sort of flattening.
>
> Thanks again,
>
> --
> Gary R. Van Sickle
>
>
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe:
> http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.antlr.org/pipermail/antlr-interest/attachments/20081220/4f0cdb7f/attachment.html