[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FYI: fix %start after first rule
From: |
Joel E. Denny |
Subject: |
Re: FYI: fix %start after first rule |
Date: |
Sun, 3 Sep 2006 16:26:55 -0400 (EDT) |
On Sun, 3 Sep 2006, Akim Demaille wrote:
>
> Le 20 ao?t 06 ? 06:15, Joel E. Denny a ?crit :
>
> > + Allow %start after the first rule.
>
> I don't understand the point of this change
I had three motivations:
1. parse-gram.y already allowed %start in the rules section. I'm afraid I
didn't give much thought as to whether it makes sense to have this
ability. Bison already allowed it, but it malfunctioned, so I fixed it.
2. I'm experimenting offline with some Bison extensions (that I haven't
previously discussed here) for which it's also wrong to assume the first
LHS is the default start symbol. Fixing #1 fixed this problem. Of
course, I don't believe Bison should evolve to accommodate my offline
tinkering. I just saw this as more evidence for point #3.
3. In general I think it's easier to evolve Bison when the syntax analysis
of the user grammar file is a separate phase from the semantic analysis as
much as possible. That is, Bison shouldn't try to understand user
declarations until it has read them all. Recent efforts to allow some
declarations to be commutative have shown the value of this approach.
>, but I can
> recognize the pattern where we don't have the same
> opinion :)
You mean commutativity?
> I'm not in favor of too much commutativity. I agree
> Bison already supports a lot of such commutativity, but
> it was wrong IMHO. We should encourage a specific
> coding style.
In many cases, I agree that we should encourage a specific coding style.
Requiring %start to be in the definitions section maybe always makes
sense. I won't argue if we change parse-gram.y accordingly (but I hope we
won't revert the changes I made). We can always change it back later if
we discover a need.
In other cases, I think we should trust the user to figure out what is the
right style for his grammar. For example, I *sometimes* like to be able
to declare `%type <my_field> my_nt' next to the one set of rules for which
my_nt is the LHS. Other times, I find it clearer if all symbols of type
<my_field> are together in the definitions section.
Joel