[Top][All Lists]

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

Re: precedence partial order and generic conflict handling

From: Joel E. Denny
Subject: Re: precedence partial order and generic conflict handling
Date: Sat, 20 May 2006 15:58:30 -0400 (EDT)

I just noticed this went off list....


---------- Forwarded message ----------
Date: Sat, 20 May 2006 03:29:11 -0400 (EDT)
From: Joel E. Denny <address@hidden>
To: Luo Gang <address@hidden>
Cc: Akim Demaille <address@hidden>, Derek M Jones <address@hidden>
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.


reply via email to

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