[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Akim Demaille
Subject: Re: [PATCH] Factor %FLAG at scan level.
Date: Wed, 8 Apr 2009 14:58:36 +0200

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

- we should probably also have priority management so that the grammar
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:

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.

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 -- Without realizing that's in the makefile, he adds %skeleton "my-" to the grammar file and types make. It may take him some time to realize why the changes he made to to create have no effect
on his test cases.  I think Bison needs to be sure to warn about the

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)

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]