[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: symbol declarations after rules
From: |
Joel E. Denny |
Subject: |
Re: symbol declarations after rules |
Date: |
Thu, 22 Jun 2006 22:06:48 -0400 (EDT) |
On Thu, 22 Jun 2006, Paul Eggert wrote:
> "Joel E. Denny" <address@hidden> writes:
>
> >> Does order matter elsewhere?
> >
> > A few places at least. %union for dividing the pre-prologue blocks from
> > the post-prologue blocks.
> > Computing the start symbol (assuming no %start).
> > Reduce-reduce conflict resolution.
>
> I suspect these are inevitable due to backward compatibility concerns
> with Yacc.
Oh sure, but it's nice when Bison can offer cleaner alternatives. For
example, %start.
This discussion has emboldened me to propose a full alternative to
prologue blocks (and I may be stealing it from a post from Akim, but I'm
not sure). I don't think the user should have to use %union to organize
prologue blocks. That interface is subtle and restrictive.
For example, as I've mentioned before, the user may not want a %union. I
addressed this by making %after-definitions and %before-definitions also
divide the pre-prologue blocks from the post-prologue blocks. In doing
so, I introduced more subtle order-dependent rules to keep up with.
A few days ago, I was working on generating a grammar file. For reasons
that are difficult to explain, it was most convenient to generate a %union
declaration at the very top of the file. This meant that all my prologue
blocks were post-prologue blocks. Yes, I found a work-around, but I think
it would have been easier if I could have just *declared* that certain
prologue blocks were pre-prologue blocks.
In general, order-dependent declarations are subtle and restrictive. The
user should be able to organize his grammar file as he sees fit.
As I've mentioned before, I think the terms pre-prologue and post-prologue
aren't quite right. What if we offer %before-header and %after-header as
order-independent alternatives? That is, they would be blocks of code
inserted into the code file before and after the contents of the header
file.
In that case, we could go back to having only %union separate the
Yacc-style pre-prologue blocks from post-prologue blocks. That is, I
would remove the influence of %before-definitions and %after-definitions
on the old prologues. Less order-dependent rules to remember.
Just to make sure I'm being clear: before the first %union, a prologue
block would have the same function as %before-header does anywhere.
After that %union, a prologue block would have the same function as
%after-header does anywhere.
What do you think?
> > Precedence declarations.
>
> I'm not aware of this one. Does Yacc allow this? If so, I guess we're
> stuck with allowing this as well.
I just meant that the Yacc way of declaring static (token) precedence is
by the order of the precedence declarations. %dprec uses numbers instead.
I believe Akim has talked about partial/modular precedence declarations
that may provide a cleaner alternative. He's also talked about the
reduce-reduce conflict resolution issue.
> > One %define can override an earlier %define.
>
> Yacc doesn't have %define. Can we change this to generate a
> diagnostic instead of silently ignoring the earlier definition? Or is
> there some use for overriding?
I'm not sure. I don't know the history here. Maybe Akim knows?
> Thanks for summarizing the situation.
It's very possible I've missed some things.
Joel
- symbol declarations after rules, Joel E. Denny, 2006/06/22
- Re: symbol declarations after rules, Paul Eggert, 2006/06/22
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/22
- Re: symbol declarations after rules, Paul Eggert, 2006/06/22
- Re: symbol declarations after rules,
Joel E. Denny <=
- Re: symbol declarations after rules, Paul Eggert, 2006/06/22
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/22
- Re: symbol declarations after rules, Paul Eggert, 2006/06/22
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/22
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/23
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/23
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/23
- Re: symbol declarations after rules, Akim Demaille, 2006/06/27
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/26
- Re: symbol declarations after rules, Joel E. Denny, 2006/06/26