Re: Bison 1.30f

[Akim Demaille]

>>>>> "Paul" == Paul Eggert <address@hidden> writes:

>> From: Akim Demaille <address@hidden> Date: 13 Dec 2001 11:36:54
>> +0100
>> 
>> bison is meant to produce compilation units, not headers.  So I
>> fail to see why it is so important not to import the standard
>> symbols.

Paul> I think it was one of RMS's original goals when writing Bison.

`writing Bison' seems a bit excessive to me.

Paul> That is why the manual says "Aside from the token type names and
Paul> the symbols in the actions you write, all variable and function
Paul> names used in the Bison parser file begin with `yy' or `YY'."

That's true for all the Yacc flavors I know.

Paul> Also, strictly speaking it is required for POSIX conformance.
Paul> POSIX 1003.1-2001 says:

Paul>    Conforming applications shall not use names beginning in yy
Paul> or YY since the yacc parser uses such names. Many of the names
Paul> appear in the final output of yacc, and thus they should be
Paul> chosen to conform with any additional rules created by the C
Paul> compiler to be used. In particular they appear in #define
Paul> statements.

I do agree Paul.  But we are referring to different levels of
cleanness.

The most basic level is wrt global symbols and #defines, since they
cover the whole file.  On this regard, Bison and Yaccs are clean.

The next level is cleanness wrt to inside the rules themselves, which
is what you addressed recently.  I must say that you reach a point
which seems excessive to me, see for instance yysize when augmenting
the stacks: this is not inside the any user space at all, but
yyoverflow.  But then I agree killing them all is much easier and less
error prone than spotting just those that need it.

Then, cleanness wrt imported symbols.  To me, this is just impossible.
And the more efforts one makes, the worse it gets.  Because bison
decides to include or stdio.h depending upon options, you just cannot
safely have your code use stdio.h: risks of including it twice, or not
at all.  IMHO, it should *always* include, or *never* include,
regardless of the options.  But people are used to the current weird
status.

Finally, ultimately, cleanness wrt non C languages.  That's not Bison
immediate goal :)



And now for something completely different: is YYDEBUG (and yydebug) a
POSIX stuff?  I suppose -v (generation of the textual representation
of the automaton) is, right?

Thanks!