Re: Misc. minor bison 1.33 bugs and annoyances patched

[Akim Demaille]

>>>>> "Bruce" == Bruce Lilly <address@hidden> writes:

>> Hi!  Thanks for the patch.  But one first problem is that we take
>> single task patches, yours addresses different issues.

Bruce> Aside from the yydebug comment, these are all compilation
Bruce> issues related to the output file produced by bison.

Still different issues.



>> I very much agree with your intention here, but there are other
>> major changes in Bison, and first of all, I want them to be
>> finished before starting any other deep change.  You will certainly
>> argue that your patch is not profound, but it is: it is part of
>> things that must be carefully thought in conjunction with multiple
>> language output etc.

Bruce> The patch should work with K&R C, ANSI C and C++.  What else
Bruce> did you have in mind?

Java, C# and Scheme are the next targets.  In other words, we are
moving away from CPP.



>> I plan to move to a Bison parser for the .y files, which might
>> render these obscure CPP macros completely obsolete.

Bruce> Well, the output from bison, no matter how it is generated,
Bruce> still needs to be compiled. In the case of reentrant parsers,
Bruce> it is desirable to have the argument explicitly typed correctly
Bruce> so one can write ruleset action code like:
x-> a = x->b + x->c % x->d;
Bruce> instead of ((struct foo *)x)->a = ((struct foo *)x)->b +
Bruce> ((struct foo *)x)->c % ((struct foo *)x)->d; as the latter gets
Bruce> quite tedious for large grammars.

That's not my point.  My point is that the issues you raise are indeed
to be solved, but they are part of a bigger picture, and I'm not
willing to commit Bison to some partial solution without having
thought to the whole picture.

Your solution might very well be the very right one, but this has to
be checked.

For a start, you did not inspire the name of the macro with the other
similar macros (Cf Flex' for instance), which is enough for me.




>> | 2. explanation of yydebug for "--akim".
>> 
>> I understood this bit since, and I'm still shocked it works!  I
>> find this incredibly ugly!  I'll adjust the comment, thanks for the
>> impetus.

Bruce> It's not such a big deal; it beats forcing the caller to define
Bruce> it.  And if the -p option is used multiple parsers can have
Bruce> debug mode set independently.

I was referring to the ``feature'' offered by the compilation suite,
not Bison's taking advantage of it.



>> The idea is OK, but then, please work on the CVS version of Bison,
>> as 1.33 is basically dead (only maintenance).

Bruce> Has bison.simple changed so much in the CVS version that the
Bruce> patch cannot be applied?

Yes.


>> | 4. avoided "constant conditional" compiler diagnostics for |
>> bison.simple due to useless do - while (0) in macros.
>> 
>> This is on purpose.

Bruce> I understand that one might care about being able to write
Bruce> YYDPRINTF(foo); instead of YYDPRINTF(foo) and the patch
Bruce> provides for that without the annoying compiler complaints
Bruce> (which appear in every bison-generated parser).

... with _your_ compiler.


>> | 5. proper prototype declaration for __STDC__ as well as | for
>> __cplusplus.
>> 
>> This is interesting.  I would apply it to CVS Bison.

Bruce> Another compiler diagnostic issue; several similar ones were
Bruce> fixed between 1.28 and 1.33, but the yyparse prototype seems to
Bruce> have been missed.

Yes, I agree.  In fact, I'd welcome it for 1.33 too.

Thanks!