Re: problem compiling bison with gcc 3.0.5

[Hans Aberg]

At 13:50 +0100 2002/03/02, Martin Trautmann wrote:
>please send only to the list. I subscribed.

You will have to live with the extra copies: It is impossible to keep track
of who should have them and who should not; those not on the list should
have them. Write a filter to get rid of the extra copies and/or sort the
stuff into an appropriate mailbox.

>My problem is, that I want to create two parallel expression parsers:
>exp:
>     simple_exp  %prec normal
>   | complex_exp
>;
>simple_exp: simple_exp '+' simple_exp
>   | '+' simple_exp %prec UMINUS
>   | any_simple_token
>;
>complex_exp: complex_exp '+' complex_exp
>   | '+' complex_exp %prec UMINUS
>   | simple_exp %prec very_very_low
>   | any_complex_token
>;
>
>The complex expression creates parse trees in the memory but it
>shouldn't be used for simple expressions like 1 + 1;
>The generated parser works like I want it, but why isn't it possible to
>tell with %prec very_very_low that it shouldn't be used when there is an
>alternative rule with %prec normal.

It sounds as though that you want to perform some kind of optimization that
cannot be worked out syntactically: my guess is that your any_simple_token
and any_complex_token overlap. So, if this is the case, try to just use one
type of "expression" and "any_token" etc, and work it out in the actions
instead.

If you use C++, write a polymorphic hierarchy: Then it is easy to write say
a polymorphic operator+() that performs the operations you want.

>>>   * passing some objects to the yyparse() function
>>>
>>
>> Check YYPARSE_PARAM, Bison manual sec 4.2.4.
>>
>I am using YYPARSE_PARAM at the moment, but its very nasty. Its only
>possible to pass a void* pointer. This would be very easy to make the
>type changeable.

Oops: I thought those Bison developers had changed that. :-)

Why don't you make your own bison.simple skeleton file?; it's easy. -- If
you experience great success, you can submit the patch to Bug Bison. :-)

  Hans Aberg