bug-bison
[Top][All Lists]
Advanced

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

Re: Ambiguity involving two parse stacks reducing on the same rule


From: Frank Heckenbach
Subject: Re: Ambiguity involving two parse stacks reducing on the same rule
Date: Thu, 10 Mar 2005 21:53:37 +0100
User-agent: semail 20050101

Laurence Finston wrote:

> > > v: e
> > >  | e e
> > >
> > > e: 'a'
> > >  | 'a' 'a'
> > >
> 
> > [...] my question was if there was a way
> > to get `%dprec' to work in such a case without having to rearrange
> > the grammar. This question still stands, and perhaps someone here
> > has an idea ...?
> 
> Perhaps structuring your grammar in a way similar to the following
> example would help to solve your problem.  This is just off the
> top of my head, so I don't know if it will work, and
> you would probably have to fiddle with it.

I suppose so. But since this example is vastly simplified, in
practive this would involve quite some changes, so I'm hoping to
avoid it somehow.

To the bison developers, is there any chance of getting `%dprec' to
also consider the subproductions for the dynamic priorities?

Or, alternatively, could `%dprec' be made to call a user-supplied
function to decide about dynamic priorities? This would be similar
to `%merge', except that the function would be run *before* any
semantic actions of the split parsers are executed.

E.g., if one of the branches would, in its actions, output a
semantic error message, there is no way to undo this in `%merge'. In
contrast, a `%dprec'-function could look at the two parses and
reject the "wrong" one before its semantic actions are executed.

A problem might be how to inform the function about the different
parses. While a merge function has the alternative semantic values,
these would not exist at the time a `%dprec'-function is called ...

Frank

-- 
Frank Heckenbach, address@hidden
http://fjf.gnu.de/
GnuPG and PGP keys: http://fjf.gnu.de/plan (7977168E)




reply via email to

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