Re: FYI: fix %start after first rule

[Joel E. Denny]

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