[Top][All Lists]

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

precedence partial order and generic conflict handling

From: Joel E. Denny
Subject: precedence partial order and generic conflict handling
Date: Fri, 19 May 2006 14:54:37 -0400 (EDT)

There's been some interest lately in implementing partial order support 
for precedence.  Actually, there are a number of items in the TODO list 
centering around conflicts.

Starting about here:

Derek M. Jones and I have briefly revisited an idea for GLR parsers.  The 
idea is to allow users to specify an action that should execute whenever 
the parser encounters a conflict.

I'm thinking this conflict action could be declared in the definitions 
section with %conflict in a similar manner to %initial-action.  The user 
code could access YYABORT, YYERROR, YYACCEPT, yyerror, %parse-param's, 
etc. and do whatever else the user wishes in order to handle/report/log 
the conflict.  Most importantly, he could also specify which of the 
conflicting actions should be kept and which should be discarded.

In theory, I see no reason why this feature must be limited to GLR 
parsers.  The only difference from LALR(1) is what the parser does when 
%conflict leaves multiple alternate actions remaining.  Similar to %merge 
with respect to %dprec, I envision %conflict being invoked after any 
%nonassoc, %left, %right, and %prec eliminations.

It seems to me that a user could employ %conflict to implement precedence 
with partial orders, reduce/reduce conflict resolution, and associativity 
in whatever way he chooses.  Of course, this requires we provide the user 
with all the information he may need.  I've formed some ideas on how this 
would go, but I'd first like to see if this sounds interesting to others.


reply via email to

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