[Top][All Lists]
[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 `;'.
- Re: Bison patch for POSIX and Yacc compatibility with %union, Akim Demaille, 2003/01/13
- Re: Bison patch for POSIX and Yacc compatibility with %union, Paul Eggert, 2003/01/13
- Re: POSIX_ME_HARDER (Was: Bison patch for POSIX and Yacc compatibility with %union), Akim Demaille, 2003/01/15
- Re: POSIX_ME_HARDER (Was: Bison patch for POSIX and Yacc compatibility with %union), Paul Eggert, 2003/01/16
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/19
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/20
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/21
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/22
- Re: %union foo bar baz and others { ... }, Akim Demaille, 2003/01/22
- Re: %union foo bar baz and others { ... }, Paul Eggert, 2003/01/22
- Re: ending ; (Was: POSIX_ME_HARDER),
Akim Demaille <=
- Re: ending ; (Was: POSIX_ME_HARDER), Paul Eggert, 2003/01/22
- Re: Reserved name classes, Akim Demaille, 2003/01/21
- Re: Reserved name classes, Paul Eggert, 2003/01/22
- Re: Paul and I (Was: POSIX_ME_HARDER), Akim Demaille, 2003/01/22