Re: %union foo bar baz and others { ... }

[Akim Demaille]

| Akim Demaille <address@hidden> writes:
| > I don't know how ANTLR makes the difference between delayed code, and
| > immediately executed code, that allows the implementation of something
| > like a "cut" to prune the wrong parses.
| 
| I'm no ANTLR expert, but I think they put a "?" after the action,
| E.g.:
| 
|    stat:
|            {isTypeName(LT(1))}? ID ID ";"
|        |   ID "=" expr ";"
|        ;
| 
| The lexical analysis of {...}? actions in ANTLR does not seem to
| differ from that of ordinary actions.  I'd guess that the same would
| be true for Bison; if so, it'll be trivial to add this syntax.  If my
| guess is wrong, though, there will be problems of course.

In the case of BTYacc, you seem to be correct.  In addition, I'm not
in favor of postfix modifiers, I think prefix is better for the human
and the machine.


| > The SC_AFTER_IDENTIFIER pieces of code is additional code,
| > additional burden, that should be removed from Bison.
| 
| But this would remove code that supports a POSIX requirement.  Even if
| we decided not to conform to POSIX by default (which I don't yet see
| the need for, due to backward-compatibility concerns),

I don't think that this backward compatibility is really an issue.
One hardly finds grammars without semicolons, and most of those that
fail are due to mistakes, missing semicolons.


| we would need
| to conform if the POSIXLY_CORRECT environment variable is set.  And to
| do that, we would need SC_AFTER_IDENTIFIER, or something else equally
| complicated.  I don't see any easy way out of this complexity.
| 
| Hmm, perhaps you meant to say "SC_PRE_CODE" rather than
| "SC_AFTER_IDENTIFER" here?  It seems more relevant here.  To my mind
| the SC_PRE_CODE stuff is less defensible than the SC_AFTER_IDENTIFIER
| stuff, as it supports something that is not a POSIX requirement, and
| it's a worse hack to the lexer.

What I do not like is that this code is really complex, and would be
infinitely clearer if handled elsewhere.

Here is my proposal to mediate between our two concerns:

- keep ';' optional, but make it issue a warning (with the strong
  intention to remove this support in the future if *any* new feature
  in Bison becomes easier to implement if it were mandatory).

- remove the 'id:' stuff from the scanner per se, but...

- introduce a buffering between the scanner and the parser that
  groups an 'id' followed by a ':'.

- get ready to cease the parsing of the actions in the grammar
  scanner.  This is also why I had the global variable that makes the
  distinction between being expecting an action or not.