help-bison
[Top][All Lists]
Advanced

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

Re: x + (y) + z


From: Frank Heckenbach
Subject: Re: x + (y) + z
Date: Wed, 9 Mar 2005 05:58:53 +0100
User-agent: semail 20050101

Derek M Jones wrote:

> >> Your grammar contained a single %merge.  I thought at
> >> least two are required?
> >
> >All the involved (top-level) rules must have a `%merge'. In the
> >original example, both happened to be the same rule.
> 
> Thanks for a great example.  It looks like the implementation of
> %merge is different from that of %dprec (big mistaken assumption
> on my part).  After reading the source I still don't understand why
> yyparse handles them differently.

Is it really different? `%dprec' obviously needs two different
precedences, therefore two different rules.

`%merge' in contrast actually requires the same merge function in
all affected places.

So I can imagine yyparse actually handles them the same way -- until
the point where the dprecs are compared (for inequality) or the
merge functions are compared (for equality).

So it really seems there are cases that `%dprec' can't handle.
Attached is the simplest one I could come up with. It's obviously
ambiguous, and even adding `%dprec' in every single rule does not
resolve it.

AFAICS, that's because the conflict is between

  v -> e e -> ('a' 'a') 'a'

and

  v -> e e -> 'a' ('a' 'a')

I.e., at the time the ambiguity is deteced the choice is between two
applications of the same rule (v -> e e) which cannot have different
`%dprec'. Whereas at the time the choice is between the two e rules,
which have different `%dprec', the parser doesn't know yet that
there will be an ambiguity. So it might indeed be useful to somehow
look at the sub-productions when deciding dynamic precedences ...

BTW, I'm interested in this case as well since it might occur in one
of my grammars. `%merge' probably isn't an (easy) option for me
because of semantic actions. Of course, I know that rearranging the
grammar will help, and if it's the only way, I guess I'll have to do
it, but it would be nice if there's some way without rearranging.

> My expression parsing problems are now solved.
> >The second example works and shows all four trees (after fixing a
> >few precedences in the grammar) with another `%merge' -- in the
> >final grammar you might need some more.
> 
> This is a great example (the attached version tries to be visually
> simpler).  It ought to be included in the bison documentation to
> show how the details of %merge differ from those of %dprec.

I have no objections, and I have already signed a copyright
assignment for bison, so no problem from my side. I don't know if
your changes are considered non-trivial enough to require an
assignment as well, and I don't know if any bison maintainers are
reading this here. Otherwise you might want to post it to bug-bison,
possibly already as a diff to the texinfo file with accompanying
notes in the text.

Frank

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

Attachment: dprec-problem.y
Description: Binary data


reply via email to

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