[antlr-interest] Disregarding subrule ordering

[Bryan Ewbank]

Just adding the necessary actions to the parser works too, of course. 
There's no fundamental reason you /can't/ to it in the parser; I just
find that a separation of concerns makes everything simpler.

My rule of thumb is: if it isn't purely syntax, it doesn't belong in
the parser.  That said, yacc grammars generally blur the line because
there's no concept of tree walking where you can easily place the
semantic rules.

... ... ...

By the way, make sure to add the "|" between the alternatives in the
major block, or you will spend hours looking - and seeing it as if
they are there...

Change this:

    object:
        KW_OBJECT
        IDENTIFIER
        LBRACE { //set all bools to false here
        (
            { !param1bool }? param1 { param1bool = true; }
            { !param2bool }? param2 { param2bool = true; }
            { !param3bool }? param3 { param3bool = true; }
            { !optParam1bool }? optParam1 { optParam1bool = true; }
            { !optParam2bool }? optParam2 { optParam2bool = true; }
        )*
        RBRACE { if(! (param1bool && param2bool && param3bool) ) throw ....)
    ;

To this:

    object:
        KW_OBJECT
        IDENTIFIER
        LBRACE { //set all bools to false here
        (
        |   { !param1bool }? param1 { param1bool = true; }
        |   { !param2bool }? param2 { param2bool = true; }
        |   { !param3bool }? param3 { param3bool = true; }
        |   { !optParam1bool }? optParam1 { optParam1bool = true; }
        |   { !optParam2bool }? optParam2 { optParam2bool = true; }
        )*
        RBRACE { if(! (param1bool && param2bool && param3bool) ) throw ....)
    ;

On 12/2/05, Royne Borrud <royne.borrud at gmail.com> wrote:
> Thanks for the suggestions. I'm new to ANLR in general and treeparsers
> in particular, so I'll have to look into that a bit further I guess.
> Is there some rule-of-thumb for when to use treeparsers? I've only
> done some small grammars so far (mostly flex/bison), and haven't seen
> the *need* for an extra step with a treeparser so far, though it might
> simplify post-processing.