|
From: | Derek M Jones |
Subject: | Re: Exceeded limits of %dprec/%merge? |
Date: | Fri, 19 May 2006 03:35:46 +0100 |
User-agent: | Thunderbird 1.5 (Windows/20051201) |
Joel,
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.
Also, what is wrong with using my_yyreportAmbiguity to resolve an ambiguity? For my current problem I can rewrite the grammar to stop it happening, but this might not always be the case. There may be situations where resolving the issue in my_reportAmbiguity provides a much neater solution.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.
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. 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. -- Derek M. Jones tel: +44 (0) 1252 520 667 Knowledge Software Ltd mailto:address@hidden Applications Standards Conformance Testing http://www.knosof.co.uk
[Prev in Thread] | Current Thread | [Next in Thread] |