[PATCH 0/2] RFC: api.value.type

[Akim Demaille]

These patches (well, the second one) show what I have in mind about
api.value.type.  Its NEWS entry is quoted below.  It's available
currently as the branch api.value.type.

Please, comment on this!  I plan to make a beta shortly so that we
can get as much feedback as possible before making the real release.

The documentation uses YYSTYPE about everywhere.  I very much disklike
this, yet it is what users of Yacc should do.  Yet this is Bison, not
Yacc, so I think I will transform most of these YYSTYPE into
api.value.type.

           *** If you think this is wrong, speak up ***

A better description of api.value.type needs to make its way in the
documentation, with a dedicated section about "Defining the type
of semantic values" (which would subsume the section about %union).
In particular, so far there is nothing cute provided for yylex to
define yylval in the case of api.value.type=union (one must use
casts, see the test cases in types.at).


What remains to be done before the release:

- clean up issues about YYSTYPE vs. api.value.type

- see if api.value.type="" can be handled properly

- more checks (e.g., using %union, but api.value.type != %union)

- maybe Dennis's push-parser for Java

- maybe %empty marker for empty rules

- ???

----------------------------------------------------------------------

** 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"

  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"

  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 u
        {
          int ival;
          char *sval;
        };
      };
    }
    %define api.value.type "struct my_value"
    %token <u.ival> INT "integer"
    %token <u.sval> STR "string"


Akim Demaille (2):
  c++: rename b4_semantic_type_declare as b4_value_type_declare
  api.value.type: implement proper support, check, and document

 NEWS               |  56 +++++++++++++++++++++++
 data/c++.m4        |  25 +++++-----
 data/c.m4          | 115 ++++++++++++++++++++++++++++++++++++++++++----
 data/lalr1.cc      |   2 +
 data/variant.hh    |   8 ++--
 data/yacc.c        |   1 -
 doc/bison.texi     |  82 +++++++++++++++++++++++++++++++--
 tests/local.mk     |   3 +-
 tests/testsuite.at |   7 ++-
 tests/types.at     | 131 +++++++++++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 399 insertions(+), 31 deletions(-)
 create mode 100644 tests/types.at

-- 
1.8.1.2