[Top][All Lists]
[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)
dprec-problem.y
Description: Binary data
- Re: x + (y) + z, (continued)
- Re: x + (y) + z, Hans Aberg, 2005/03/06
- Re: x + (y) + z, Hans Aberg, 2005/03/06
- Re: x + (y) + z, Derek M Jones, 2005/03/06
- Re: x + (y) + z, Frank Heckenbach, 2005/03/07
- Re: x + (y) + z, Derek M Jones, 2005/03/07
- Re: x + (y) + z, Frank Heckenbach, 2005/03/07
- Re: x + (y) + z, Derek M Jones, 2005/03/07
- Re: x + (y) + z, Frank Heckenbach, 2005/03/07
- Re: x + (y) + z, Derek M Jones, 2005/03/08
- Re: x + (y) + z,
Frank Heckenbach <=
- Ambiguity involving two parse stacks reducing on the same rule, Derek M Jones, 2005/03/09
Re: x + (y) + z, Hans Aberg, 2005/03/06
Re: x + (y) + z, Hans Aberg, 2005/03/07
Re: x + (y) + z, Hans Aberg, 2005/03/07
Re: x + (y) + z, Hans Aberg, 2005/03/07