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

[Ron Burk]

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"); }