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

[Joel E. Denny]

Hi Akim,

On Sat, 23 Feb 2013, Akim Demaille wrote:

> 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

The precedence of "and" vs. "or" is confusing here.  Replacing "and" with 
"and either" would clarify it, I think.

> results in undefined behavior.

Instead of leaving it as undefined behavior, could there be a #error?

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

s/examplified/exemplified/

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

Nice.

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

What does the "yytype_" prefix mean?

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

This seems troublesome to me for two reasons.  First, it means a user 
typedef name "variant" cannot be used, and that's a strange restriction.  
(Fortunately, "union" and "%union" are not in the user namespace.)  
Second, it means there's no clean way to extend Bison's special values for 
api.value.type in the future.  Could we have some notation to move special 
values into a separate namespace from user type names?  One of the 
following, maybe:

  %define api.value.type "type: foo"
  %define api.value.type "{foo}"
  %define api.value.type {foo}