>>>>> "Hans" == Hans Aberg <[EMAIL PROTECTED]> writes:
Hans> At 14:49 +0100 2002/01/12, Akim Demaille wrote:
>> | or_expr: | expr {} | | or_expr OR or_expr {}
>> |
>> | ... | ANSWER expr WITH or_expr
>>
>> Hans is right: this is the kind of grammar transformation you ought
>> to do if you were using a dumb tool. But do not do that: you are
>> going to make your grammar much more complex, harder to maintain,
Hans> Who has said anything about grammar transformation?
There's a guy on this list named Hans that suggested to transform the
grammar. I agree he didn't use the word, but for his information, his
suggestion named `grammar transformation' by people working on grammars.
>> and you will even loose performances.
Hans> What performance loss do you have in your mind?
The size of the automaton. Using precedence directives is more
efficient than additional rules and nonterminals. But see the books,
or simply what I already posted several times, I'm not here to give a
lecture.
>> Just as nobody would ever program a expr/term/factor grammar for
>> arithmetics in LR,
Hans> Are you suggesting that that example should be removed from the
Hans> Bison manual?
Of course not, the example of the documentation is correct. I'm
suggesting that your suggestion is not the best means to help _here_.
>> ...you should avoid the solution above.
Hans> Of, course, the question is why?
Err, are you kidding? Have you ever implemented the idea you just
suggested? Do you really enjoy having additional nonterminals,
artificial rules, just to see Bison accept your grammar? Are you
giving advice on something you don't practice? Your suggestion is the
_last_ resort, that's why the documentation shows it: sometimes you
_have_ to.
_And_ it produces a less efficient parser, as was written right above.
_______________________________________________
Freecard-general mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freecard-general
