--- On Tue, 3/9/10, Jim Idle <[email protected]> wrote:
> From: Jim Idle <[email protected]> > Subject: Re: [antlr-interest] Using previously matched parser rule in > decision making > To: > Cc: "[email protected]" <[email protected]> > Date: Tuesday, March 9, 2010, 11:30 AM > >From anywhere in the parser: > > java.util.List stack = getRuleInvocationStack(e, > getParserName()); > > But this only works for Java and other targets that copy it > (I think C# might do it). I don't do it in C because I > prefer to take the view that the C stuff should be as close > to the metal as it can be and the programmer will choose to > add the overheads they need. > > In the JavaFX front end, this stack is used to pin down > errors a little more precisely - as it is open source you > can download the code and look at > AbstractGeneratedParserV4.java > > Jim > > > -----Original Message----- > > From: [email protected] > [mailto:antlr-interest- > > [email protected]] > On Behalf Of Kieran Simpson > > Sent: Tuesday, March 09, 2010 1:58 AM > > To: Ron Burk > > Cc: [email protected] > > Subject: Re: [antlr-interest] Using previously matched > parser rule in > > decision making > > > > 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 > > > > > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > > Unsubscribe: http://www.antlr.org/mailman/options/antlr-interest/your- > > email-address > > > > > List: http://www.antlr.org/mailman/listinfo/antlr-interest > Unsubscribe: > http://www.antlr.org/mailman/options/antlr-interest/your-email-address > 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.
