[Top][All Lists]

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

Re: RFC: Requiring the ending `;'

From: Akim Demaille
Subject: Re: RFC: Requiring the ending `;'
Date: Sun, 05 Jan 2003 13:41:16 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

 Paul> [This is following up an old thread:
 Paul> <http://mail.gnu.org/pipermail/bison-patches/2002-March/000731.html>.]

 >> From: Akim Demaille  address@hidden
 >> Date: 03 Mar 2002 23:38:10 +0100

 Paul> POSIX requires the ending ';'.  And for good reason: it allows
 Paul> the Yacc grammar to be Yaccable.

 >> Paul, my dear Paul, I think this is the first time I hear from your
 >> POSIX mouth with that much pleasure :)

 Paul> After seeing so many bug reports about this since March, I
 Paul> double-checked the POSIX spec, and it turns out that I was incorrect;
 Paul> so you may have to revise your opinion about POSIX and pleasure.

 Paul> POSIX 1003.1-2001 (as well as POSIX 1003.2-1992) requires that Yacc
 Paul> must accept rules without the trailing semicolon.  It also requires
 Paul> that rules must be accepted if they have two or more trailing
 Paul> semicolons.

 Paul> My mistake stemmed from the fact that the POSIX spec says in one place
 Paul> "A grammar rule has the form: `A : BODY ;'.", and I relied on this
 Paul> statement.  However, in a later place the spec says that the formal
 Paul> syntax "takes precedence over the preceding text syntax description"
 Paul> and the formal syntax does indeed allow grammar rules with any number
 Paul> of trailing semicolons, including zero semicolons.

 Paul> Sorry about that.

 Paul> I have drafted a patch, but it it is still not correct since it
 Paul> doesn't handle line numbers correctly.  The line numbers are a real
 Paul> pain.  I have discovered some related line-number bugs in the current
 Paul> Bison code, as well as in the test cases.  I'll try to get it done
 Paul> later this week.

This is really bad.  This is, imho, an error for this committee, as
they are not leaving us the room we might need for extensions.  And I
was indeed considering one, based on ideas/needs in BTYacc mixed with
ideas from Lemon.

Some people want to access $0, $-1 etc., and the current solutions are
awkward.  Instead of

      foo: bar baz { link ($<prelist>-1, $<postlist>0, $1, $2); }

I wanted to have Bison understand

      prelist postlist foo: baz baz {/*...*/}

But to be able to declare the ``context'' of an lhs this way, you need
to know where the previous rule ended.

So really, I'm very sad we reverted to introducing the optional `;'.

reply via email to

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