Re: [PATCH] Factor %FLAG at scan level.

[Akim Demaille]

Le 8 avr. 09 à 10:36, Joel E. Denny a écrit :

> > > > - we should probably also have priority management so that the  
> > > > grammar
> > > > file
> > > > can declare %define debug, but be overriden by -Ddebug=false.
> > >
> > > Agreed.  We need to generalize Paolo's skeleton_arg and  
> > > language_argmatch
> > > functions.  There was some discussion on correct priority some  
> > > time ago.
> >
> > I don't remember.  I'll look for it.
>
> I found it:
>
>  http://lists.gnu.org/archive/html/bison-patches/2006-12/msg00065.html

Thanks, I read it (maybe too fast though).

> But I think the main revelation is below....
>
> > > My recollection is that the command line should have higher  
> > > priority,
> >
> > Yes, definitely.

I'm glad there is some consensus here, as it was less clear in the  
thread.

> > > but
> > > there should be a warning if a grammar declaration contradicts the  
> > > command
> > > line.  If that's too harsh, the warning could be disabled.
> >
> > Hum.  Yes, let's have it disabled by default.
>
> I think there are cases where it would be more helpful if Bison  
> enabled
> the warning by default.
>
> Let's say the user is given a makefile that specifies -- 
> skeleton=lalr1.cc.
> Without realizing that's in the makefile, he adds %skeleton "my- 
> lalr1.cc"
> to the grammar file and types make.  It may take him some time to  
> realize
> why the changes he made to lalr1.cc to create my-lalr1.cc have no  
> effect
> on his test cases.  I think Bison needs to be sure to warn about the
> contradiction.
>
> Another example is where the user specifies --defines=token-defs.h  
> without
> realizing that the code base already uses a defines file specified by
> %defines "parser.h".  If the user is lucky, a compilation error  
> results.
> If he's not lucky and an old version of parser.h is still lying  
> around,
> parser.h would be included everywhere and any changes in the  
> definitions
> would not take effect.  Again, I think Bison needs to be sure to warn
> about the contradiction.
>
> Instead of allowing the user to disable the warning globally, I think
> Bison can provide a more careful and flexible solution.  Bison would  
> warn
> if --define contradicts %define, but Bison would not warn if
> --force-define contradicts %define.

I don't like the explosion of the number of options.  If you really  
want to walk that way, let's introduce more flavors of -D, say -DFOO? 
=Value that would have low priority, -DFOO!=Value to override (too bad  
it looks so much as an inequality) etc.  But it seems a bit overkill  
to me.

My fear with this warning is that I fear it will become one of these  
warnings that today make my life uselessly more complex.  Before,  
everything that was in GCC's -Wall and even -Wextra were really truly  
useful warnings that I did not want to see in my code, so I even use - 
Werror.  Now there are warnings for kids in GCC.  I hate that gcc  
requires parens here:

        if (a && b
            || c && d)

around the conjunctions (will it some day require parens for a * b + c  
* d?)

Similarly I can't write

        if (a)
          if (b)
            c;
          else
            d;

now it wants braces for the inner if!

These warnings now need either that I "fix" my code, or dive again in  
Autoconf macros to find the proper -Wno-* to use.


So I'm just worried that maybe some day I will have to add -Wno-* to  
my BISONFLAGS.

But your points make sense.  In fact, it seems quite logical that  
options that affect the file names be part of the option-based  
interface (because after all this has to be visible from tool such as  
Make), whereas parameterizing only the contents of the files belongs  
to the %directive interface.  *And* command line options are a nice  
means to play with various parameters in debug/editing sessions.

> With that solution in place, it might be fine to convert the --define
> warning to an error to make sure it's noticed.
>
> What do you think?

That in the end the question is: should the interface be tailored for  
experienced users, or novices.  Both opinions are perfectly  
defendable, but we need to make our mind once on this regard, and be  
consistent afterwards.