[antlr-interest] Unsubscribe

Mehul Thakkar mehul_303 at yahoo.com
Thu Mar 11 15:08:41 PST 2010



--- On Tue, 3/9/10, Jim Idle <jimi at temporal-wave.com> wrote:

> From: Jim Idle <jimi at temporal-wave.com>
> Subject: Re: [antlr-interest] Using previously matched parser rule in decision making
> To: 
> Cc: "antlr-interest at antlr.org" <antlr-interest at antlr.org>
> 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: antlr-interest-bounces at antlr.org
> [mailto:antlr-interest-
> > bounces at antlr.org]
> On Behalf Of Kieran Simpson
> > Sent: Tuesday, March 09, 2010 1:58 AM
> > To: Ron Burk
> > Cc: antlr-interest at antlr.org
> > 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
> 


      


More information about the antlr-interest mailing list