bison-patches
[Top][All Lists]
Advanced

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

Re: %name-prefix overrides --name-prefix?


From: Hans Aberg
Subject: Re: %name-prefix overrides --name-prefix?
Date: Thu, 14 Dec 2006 21:22:12 +0100

On 14 Dec 2006, at 21:08, Joel E. Denny wrote:

One may just go in,
changing the skeleton file at one of the places, and if there is something
already written, all will look normal. So perhaps, in the case of the
precedence rule, one should give a warning if both methods are used.

It's clear to me that %foo overriding --foo is misleading to the user
invoking Bison from the command line.

I think you're now saying the reverse could also be misleading. I agree. Imagine the user who edits the grammar file and then types make. He may not realize that the makefile invokes Bison with --foo overriding the %foo
he just wrote.

I am thinking about the psychology. In the case of writing a library override, the editing location of the user is always clear. In this case, both might be used. And any one overriding the other might be confusing.

So this suggest sticking to Paul's suggestion for now: if both are used, one gets an error.

Maybe we're trying to be too helpful, but I'm not sure.

Here's another proposal. Bison would complain about any conflict between
--foo and %foo.  However, it would let --force-foo override %foo.

I believe there are only a handful of options for which this should
actually be done:

  --defines
  --output
  --name-prefix
  --file-prefix
  --skeleton

By the way, should there even be a --language? Isn't the target language
always so tightly coupled with the grammar file that %language should
always be used instead?  Why would anyone ever want to override it?
Paolo, what do you think?

Another idea that came to my mind, which I just mention, is to separate Bison language and compiler options. Language options should then go in the .y file, and the compiler options in some other file. But perhaps this is not the practise of other compilers.

But by this idea, language options should then not be alterable by startup arguments. In particular, %language should only not be duplicated by a --language. Perhaps this idea is what you sense intuitively.

  Hans Aberg






reply via email to

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