I just noticed this went off list.... Joel
---------- Forwarded message ---------- Date: Sat, 20 May 2006 03:29:11 -0400 (EDT) From: Joel E. Denny <[EMAIL PROTECTED]> To: Luo Gang <[EMAIL PROTECTED]> Cc: Akim Demaille <[EMAIL PROTECTED]>, Derek M Jones <[EMAIL PROTECTED]> Subject: Re: precedence partial order and generic conflict handling On Sat, 20 May 2006, Luo Gang wrote: > The general %conflict sound a good solution to solve many problems about > conflicts, > but it put too much work to the users (I guess). In some cases, I agree. For example, algebraic operator precedence and associativity is natural already with %left, %right, etc. I certainly don't oppose the implementation of new specific techniques. However, I think we'll never cover all the possibilities, so having a generic dynamic mechanism should be helpful. For example, if there were an API for examining the GSS (graph structured stack) in GLR parsers, the user code in %conflict might be able to resolve conflicts by examining previous portions of the parse forest. I think that would even make sense for LALR(1) and might eliminate the need for GLR in some cases. > IMO, the users hope Bison could detect the potential conflicts, > report it and suggest them how to figure these conflicts out. That's a good point. The advantage of static conflict resolution is that Bison can compute whether conflicts have been resolved before even generating the parser code. Bison couldn't analyze the dynamic code in %conflict to compute this. I agree that this is a significant shortcoming of %conflict and weakens the appeal. Nevertheless, I think it would be possible for the user to statically declare exactly which conflicts he believes he's addressed. (Currently, he can only declare how many.) Again, I have some ideas how these declarations would go. > Hope the %conflict will be discussed more. Before I spell it out, I'd like to see if Akim or Paul might be interested in the idea. If not, I'll probably bag it for now and return to it later. Joel
