bison-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ending ; (Was: POSIX_ME_HARDER)


From: Akim Demaille
Subject: Re: ending ; (Was: POSIX_ME_HARDER)
Date: Tue, 21 Jan 2003 14:09:15 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

 >> I also ask for the reversal of the `;'-ending patch.  POSIX is wrong
 >> when it accepts rules that are not ended.

 Paul> This suggestion makes less sense to me.  The GNU coding
 Paul> standards give considerably leeway to ignore POSIX, but they
 Paul> don't give carte blanche.  Here's a quote from them:

    > Standard C and POSIX prohibit many kinds of extensions. Feel
    > free to make the extensions anyway, and include a `--ansi',
    > `--posix', or `--compatible' option to turn them off. However,
    > if the extension has a significant chance of breaking any real
    > programs or scripts, then it is not really upward compatible. So
    > you should try to redesign its interface to make it upward
    > compatible.
   
 Paul> In the case of the ';'-ending patch, any extensions that
 Paul> require an ending ';' do have a significant chance of breaking
 Paul> real programs.

First of all, there are two discussions going on.  1. POSIX is wrong,
2. Bison should depart from POSIX.

I don't even feel the need to discuss 1, it's obvious.

So let's go onto 2:

 Paul> We know this, because the Bison bug reports told us so.  So we
 Paul> should try to design extensions to make them upward compatible
 Paul> with POSIX.  So far I haven't seen why we can't do that.

 Paul> Also, if we do decide to break POSIX by default, we need to
 Paul> retain support for POSIX grammars by adding something like a
 Paul> --posix option, which would be more work for us.

I'm ready for this kind of things when it does not complicate
arbitrarily Bison, and when it does not endangers future extensions.
We are in both cases.

Look at the code!  Gosh, it hurts!  Not to mention that I don't even
understand why we did not move to the GLR parser, which is precisely
_the_ tool for these kind of non LR(1)-ness.  The result is an
absolutely hideous code because you even wanted to support the full
feature including the most unlikely complications such as

        foo /* A first comment \
        on\
         several lines*/ // and even some C++ comment!
        :
        "bar";

We could have discussed about using the GLR, we could have discussed
about some moderate compatibility with a huge warning as 1.35 did, but
I'm opposed to the current solution.

Now, as far as extensions are concerned, the lack of this ;,
supporting that it is missing, will cause us a lot of trouble.  Given
that it is not a real service in itself, given that Bison anyway is
aiming at providing better services *elsewhere*, I don't see a
problem.  Of course, something which is essential here is that one can
write something which is both POSIX _and_ Bison: just put the `;'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]