[antlr-interest] Using previously matched parser rule in decision making

Kieran Simpson kierans777 at gmail.com
Tue Mar 9 01:57:47 PST 2010


I agree Ron.

Ron Burk wrote:
> It is an interesting idea for a top-down parser generator
> to just make the parsing stack of non-terminals available
> to user actions. Whether that's easy or hard depends on
> the details of how the tool generates parser code. But
> certainly knowing the context you expect to be in is
> arguably an advantage of top-down over bottom-up
> parsing, so there's an argument to be made for making
> that information available. As I struggle to think of
> common/practical use for it, mainly error reporting or
> recovery comes to mind. But, if the syntax made it
> easy to ask things like "is X on the stack", I suppose
> there are a variety of semantic checks that could be
> made clearer and simpler than via flags and such. E.g.
> checking that a 'break' keyword in C occurs within a
> do/for/switch/while.
>
> I usually try to do things in one pass, so it may be more
> interesting of an idea to me than to someone who intends
> to build a syntax tree first before doing any actual work.
>
> Dinking with syntax:
>
> A: B
> C: B
> B:
>     { if($Stack[A])... else if($Stack[C])... else assert(FALSE); }
>
> or maybe (also?)
>
>     { if($Stack[-1]==$NonTerm[A]) ...; else ...; }
>
> or
>
> LoopStmt: Do | For | Switch | While ;
> ...
> BreakStmt: 'break'
>     { if(!$Stack[LoopStmt]) SynError("break is not inside
> do/for/switch/while.\n"); }
>
> List: http://www.antlr.org/mailman/listinfo/antlr-interest
> Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your-email-address
>   


More information about the antlr-interest mailing list