[PATCH 0/6] api.value.type support (was: rename variant)

[Akim Demaille]

Hi all,

This should be the end of a long story (and a long thread, which
started here:
http://lists.gnu.org/archive/html/bison-patches/2012-02/msg00018.html):
installing "variant" support in Bison for C++, but making this feature
more general and meaningful for C too.

I would *really really* love to have some feedback about this, as it
is a significant change in Bison.  Hopefully the best introduction to
this series of changes is probably its NEWS entry:

** Variable api.value.type

  This new %define variable supersedes the #define macro YYSTYPE.  The use
  of YYSTYPE is discouraged.  In particular, #defining YYTSYPE *and* using
  %union or %defining api.value.type results in undefined behavior.

  The %define variable api.value.type supports several special values,
  examplified below:

  The value "%union" denotes that fact that %union is used.

    %define api.value.type "%union" // implied by the next line
    %union
    {
      int ival;
      char *sval;
    }
    %token <ival> INT "integer"
    %token <sval> STR "string"

    /* In yylex().  */
    yylval.ival = 42; return INT;
    yylval.sval = "42"; return STR;

  The value "union" means that the user provides genuine types, not
  union members names such as "ival" and "sval" above.

    %define api.value.type "union"
    %token <int> INT "integer"
    %token <char *> STR "string"

    /* In yylex().  */
    yylval.yytype_INT = 42; return INT;
    yylval.yytype_STR = "42"; return STR;

  The value "variant" is somewhat equivalent, but for C++ special provision
  is made to allow classes to be used.

    %define api.value.type "variant"
    %token <int> INT "integer"
    %token <std::string> STR "string"

  Any other name is a user type to use.  This is where YYSTYPE used to be
  used.

    %code requires
    {
      struct my_value
      {
        enum
        {
          is_int, is_str
        } kind;
        union
        {
          int ival;
          char *sval;
        } u;
      };
    }
    %define api.value.type "struct my_value"
    %token <u.ival> INT "integer"
    %token <u.sval> STR "string"

    /* In yylex().  */
    yylval.u.ival = 42; return INT;
    yylval.u.sval = "42"; return STR;

This is in origin/api.value.type.

I shall wrap a beta for the next release soon, probably next week.
I haven't heard of Dennis so I don't know if Java push will be ready.

There are many changes since the previous release, including dropped
support for some archaic features, so maybe instead of 2.8, the next
Bison should be 3.0.  As a matter of fact, even the M4 guts have
significantly changed.  Opinions?

Akim Demaille (6):
  api.value.type: implement proper support, check, and document
  style: simplify the scanning of type tags
  value type: accept "->" in type tags
  doc: deprecate #define YYSTYPE in favor of %define api.value.type
  doc: move the section about "%union" where types are discussed
  doc: api.value.type union.

 NEWS               |  68 +++++++++
 data/bison.m4      |   5 +
 data/c++.m4        |  15 +-
 data/c.m4          | 121 +++++++++++++--
 data/lalr1.cc      |   2 +
 doc/bison.texi     | 437 +++++++++++++++++++++++++++++++++++++----------------
 src/scan-code.l    |   8 +-
 src/scan-gram.l    |  32 ++--
 tests/local.mk     |   3 +-
 tests/testsuite.at |   7 +-
 tests/types.at     | 170 +++++++++++++++++++++
 11 files changed, 698 insertions(+), 170 deletions(-)
 create mode 100644 tests/types.at

-- 
1.8.1.3