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
