help-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exceeded limits of %dprec/%merge?


From: Joel E. Denny
Subject: Re: Exceeded limits of %dprec/%merge?
Date: Thu, 18 May 2006 23:40:10 -0400 (EDT)

On Fri, 19 May 2006, Derek M Jones wrote:

> > > I may think I have caught all the ambiguities/conflicts that can occur.
> > 
> > You can be sure by declaring the same %merge on every rule that has the same
> > LHS symbol.
> 
> Not very elegant and it would clutter up the .y file.

I accept that it's a lot to write.  Even so, can you achieve your desired 
functionality that way?

> > Define the interface of this new function and how it should be declared.
> 
> The current definition of yyreportAmbiguity + the necessary changes
> to implement the functionality of a merge.

Can you be more specific?  Would it be declared in the definitions section 
or alongside specific rules?  Can you give an example declaration 
demonstrating both the yyreportAmbiguity and merge functionality?

> > Originally, we were discussing conflict time, and now we're back to merge
> > time.  What happened?
> 
> I'm being non-conflictional and trying to work out a friendly merge'er :-)
>
> I will have a think about the conflict question you asked.

OK.

> I have just spent ages trying to isolate what looks like an
> uninitialized variable that causes the line
> yynewItem->yyisState = yyfalse;
> in yyaddDeferredAction to dereference a null pointer.
> It occurs when lots of reductions (124+) are deferred.
> Now I cannot get it to happen on the full grammar, let alone the
> cut down one :-(
> Suggestions welcome.

There have been some fixes in this area since 2.1.  It might be more 
fruitful to wait for 2.2 to worry about tracking this down.

Joel




reply via email to

[Prev in Thread] Current Thread [Next in Thread]