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
--
You received this message because you are subscribed to the Google Groups
"il-antlr-interest" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/il-antlr-interest?hl=en.
