Re: ending ;

[Akim Demaille]

 Paul> Akim Demaille <address@hidden> writes:
 >> Look at the code!  Gosh, it hurts!

 Paul> I think the part of the code that you're concerned about is the
 Paul> <SC_AFTER_IDENTIFIER> part in scan-gram.l.  

Correct.

 Paul> But this is only 20 or 30 lines.  I don't think that such a
 Paul> small amount of code is much of a cost to support the POSIX
 Paul> requirement.

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.  I
don't like the scanner doing parser's stuff, and I'm worried about the
future extensions.  I definitely agree that the location stuff had to
be updated, considering that now things like %printer or %union is a
single token!!!  The code is certainly more complex to be able to tell
where the % is, and where the actual code is.

What I dislike in this code is that it bounds us to have the %keyword
*right* before the {}.  Had the syntax for printer be different (the
ids and then the code), we would have had to change it!



 >> 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.

 Paul> If the GLR parser solves the problem in a better way, then that would
 Paul> be great.  

It is meant to :)

 Paul> However, my impression was that the GLR parser is still a bit
 Paul> experimental, particularly when it comes to handling syntax
 Paul> errors and the like.  

Sure.  But the least thing expected from a compiler is to bootstrap
itself.  The same applies to Bison: if we want to deliver user good
parsers (which is more important than a good Bison), then this track
is a means to improve the robustness and portability of our the GLR
parser.

 Paul> I don't know of any production code that uses it yet.  So I
 Paul> didn't want to rely on it in a conservative patch to a stable
 Paul> branch.  But if the GLR parser works well it'd be nice to use
 Paul> it in the next major release (after 2.0, that is).

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


 Paul> The support for those comments between "foo" and ":" is exactly the
 Paul> same Lex code as the support for those comments between any other two
 Paul> grammar symbols.  There is no code duplication, so I don't see why
 Paul> this would be considered an extra complexity.

Sorry, I don't understand what you mean here.  I don't recall having
the scanner play gotos between two tokens.

 Paul> Anyway, POSIX requires support for C-style comments in that position,
 Paul> and such comments occur in real grammars, e.g. the Gawk grammar.  

Agreed.  The parser did that fine.

 Paul> So that patch had to continue to support them.


 >> Now, as far as extensions are concerned, the lack of this ;,
 >> supporting that it is missing, will cause us a lot of trouble.

 Paul> I don't see why it will cause us much trouble.  The only potential
 Paul> extension that you've mentioned so far is the ability to have rules
 Paul> like "a b: c d;".  I don't recall what you wanted that syntax for, but
 Paul> surely it's easy to support that extended syntax for grammars that put
 Paul> a ";" after every rule, while at the same time supporting the
 Paul> POSIX-required syntax for grammars that omit ";" after rules.  And
 Paul> even if I'm wrong and it's not easy, it will be easy enough to put a
 Paul> keyword in front of the extended rules; that will remove any
 Paul> ambiguity.  We could use "%rule a b: c d;", say.

Let's renamed %rule as ;, and we agree.