Re: ending ;

[Akim Demaille]

 >> From: Akim Demaille <address@hidden>
 >> Date: Sun, 02 Feb 2003 10:54:18 +0100
 >> 
 Paul> We could use "%rule a b: c d;", say.
 >> 
 >> Let's renamed %rule as ;, and we agree.

 Paul> :-) :-) 

 Paul> But so far I don't even see the need for "%rule".  As far as I
 Paul> can see, we can get by with ";" alone.  That is, we can
 Paul> continue to support the ";"-less rules that POSIX requires, and
 Paul> we can support new rules like "a b: c d;".  (I'll call these
 Paul> new rules "2LHS rules" as I don't exactly recall what they're
 Paul> for.)

It's not 2lhs, it's nlhs.  They would be used for instance in GCC in
place of $0, $-1 etc.


 Paul> It is true that we can't support a ";"-less rule that is
 Paul> immediately followed by a 2LHS rule.  But it seems to me that
 Paul> this compromise solution should satisfy both POSIX and you.  It
 Paul> clearly satisfies POSIX, since POSIX doesn't require 2LHS rules
 Paul> so it doesn't care that they're not supported after ";"-less
 Paul> rules.  And it should satisfy you, since you dislike ";"-less
 Paul> rules and will never use them, so you don't care whether
 Paul> they're supported before a 2LHS rule.

Sorry, but I also speak as the Bison maintainer, and I'm concerned
with additional code, and the problems it will cause when willing to
introduce new features.  You also removed the ';' from the in-grammar
declarations, so that we also have

%token foo bar baz qux: bar

whereas the code required

%token foo bar baz; qux: bar;


 >> I am not concerned by its size, but more to its goto-like logic, which
 >> is harder to track than the previous the previous code while we
 >> already have quite a complex scanner, and how anti-natural it is.

 Paul> The previous scanner was simpler, but the previous parser was
 Paul> more complicated and had some undocumented dependencies on the
 Paul> LALR(1) reduction order.  So it's not obvious that the older
 Paul> Bison was simpler and clearer overall.

I don't see what you are referring to here.  And Bison is quite
allowed to rely on itself.

 Paul> Some complexity is necessary here, because the valid contents
 Paul> of {...}  depend on the symbol that precedes the {...}.  For
 Paul> example, %union {...$$...} is not allowed, but %printer
 Paul> {...$$...} is allowed.  The old Bison code did not always check
 Paul> this properly, and sometimes dumped core.  The new code checks
 Paul> this properly, and is a bit more complicated because of this
 Paul> extra checking.

I believe it dumped core because of your code, not because of the one
there was before, and certainly not because of ;.


 Paul> Now, we could break up Bison a bit, so that scan-gram.l does
 Paul> not care about $ or @, and so that we have another scanner,
 Paul> invoked by the parser, that rescans the contents of {...}
 Paul> depending on context supplied by the parser.  This sort of
 Paul> thing will be necessary if we modify the Bison grammar so that
 Paul> one cannot predict what is syntactically allowed within {...}
 Paul> by looking at the context that immediately preceded {...}.

We also wants this because type checking (which is what happens there)
is better performed after parsing that during.  That's simpler, and
more modular.  It will also make it possible to support other syntaxes
for action code instead of something bound into the reader.


 Paul> However, it seems to me that there will be some unavoidable
 Paul> complexity if we make such a change.  We'll have to scan the
 Paul> {...} twice, and we'll have to duplicate the code that scans
 Paul> {...}, which will be a bit of a pain since we'll have to
 Paul> duplicate scanning through comments, strings, C99 multibyte
 Paul> constructs, etc.  Another possibility is for scan-gram.l to
 Paul> return something more-complicated than a string for the result
 Paul> of the {...} scan, but this also adds complexity.  Also, we'll
 Paul> have to explain the extra complexity to the user.

What do you mean?  How is the user concerned about this?  (but for the
mandatory ; which has already vastly spread itself in the world).



 >> Anyway, I'm still actively lobbying for restoring the previous
 >> situation, where ; is mandatory.

 Paul> It's OK to make ";" mandatory in grammars that use future Bison
 Paul> extensions like "a b: c d ;", since that won't break existing
 Paul> code.  However, I don't see the technical need for breaking
 Paul> existing code by making ";" mandatory in Yacc grammars and in
 Paul> old Bison grammars.

No, I'm making it mandatory for any grammar.  The current grammar is
ugly, and I don't trust it.