Re: append-semicolon-to-action backward compatibility patch

[Akim Demaille]

 >> From: Akim Demaille <address@hidden>
 >> Date: Wed, 08 Jan 2003 09:43:19 +0100

 >> It is also dangerous for C itself, as you have discovered for %union.

 Paul> Sorry, I don't follow this point.  How can inserting an extra
 Paul> semicolon cause harm?  How is %union relevant here?

I was referring to the added risk of seeing `;' being added to a {}
block which is not actually meant to be code.  I think I read a patch
which was related to such a failure, but maybe my memory's wrong, or
is confused with something else.



 Paul> What I'm more worried about is users who say "It works with Bison
 Paul> 1.35, it doesn't work with newer Bisons, so I'll keep using the older
 Paul> Bison.  I don't have time to futz with getting grammar fixes
 Paul> propagated upstream."  At least one Debian maintainer took this
 Paul> approach, if memory serves.  And he had a point.

I think that new helping features can outweigh the existing
discontinued support for accidental feature.  This is my opinion, but
I do understand yours.  It's just that I really dislike complications
in the code just for supporting something that I would hardly call a
feature.


 >> Making a stricter Bison also helps in getting
 >> more robust and portable grammars.

 Paul> True, but the first goal in Bison is not to build robust and portable
 Paul> grammars.  It is to encourage the use of free software.  We shouldn't
 Paul> discourage the use of Bison compared to Yacc, unless there is an
 Paul> important technical reason to do so.  I don't see how this relatively
 Paul> minor issue qualifies.

One point :)



 >> Today, someone could write a Yacc grammar, use bison on it, and have
 >> it work.  Then she passes her file to someone willing to use yacc,
 >> and boom, it fails for these `;'.

 Paul> True.  But that's also true for other Bison extensions.  I don't see
 Paul> this as an argument against this particular extension.

I make a huge difference between this `feature' and say %location or
%glr.



 >> The ratio betwen costs and benefits seem quite high to me.  There is
 >> no real added value.

 Paul> The only added value is compatibility with older Bison versions.
 Paul> But this is a real added value; it should not be underestimated.
 Paul> And the cost is quite small, as far as I can see.

I guess this is where we feel different.


 Paul> I have started to prepare a patch for a --pedantic option to
 Paul> Bison, which will catch the use of extensions like this.  I
 Paul> think it should wait until after Bison 2.0 is out, though.
 >> 
 >> I have had similar plans for months too.  But I'm willing to go onto
 >> something like --warnings/$WARNINGS in Autoconf and Automake.  We have
 >> the support lib in Perl, we need to implement it in C, then many
 >> project would benefit from such a thing.

 Paul> Sorry, I don't follow this.  I don't know what --warnings is, or why
 Paul> Automake's warnings are relevant to Bison's warnings.

I understand.  I'll send you privately a thread of a discussion I had
with friends discussing this into more details.