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

[Joel E. Denny]

Hi Akim,

On Mon, 25 Feb 2013, Akim Demaille wrote:

> > (Fortunately, "union" and "%union" are not in the user namespace.)
> 
> Exactly.  At some point I meant to have only "union", and use
> the "variant" implementation when in C++ skeletons.  But the
> user interfaces are really different then at the yylex level.
> (but anyway lalr1.cc _is_ a different API, so this argument
> is very weak).
> 
> I'm am still not sure it was the best choice, maybe I should
> really replace "variant" by simply "union" in lalr1.cc.
> Any opinion?

I'd have to study bison's variant support, but I'm afraid I haven't yet.

> > 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}
> 
> In your examples "foo" is one of the special types, right?

I meant it to be a type in the target language.  Thus, typedef names (such 
as variant) are in a separate namespace from your keywords union, %union, 
and variant.

> That would be a new notation in Bison, how about something
> like this:
> 
> %define api.value.type ""
> %define api.value.type "int"
> %define api.value.type "%union-directive" // was %union
> %define api.value.type "%union"           // was union
> %define api.value.type "%variant"

I don't like that all other %define variables that have keyword values 
don't use % for those values.  Moreover, the following by itself looks 
like it means %union is to be used:

  %define api.value.type "%union"

In general for %define, I wonder if we should continue to require quotes 
for values that are keywords (such as variant, full, none).  For values 
that are code in the target language, braces seem nice.  (For other 
arbitrary values, such as file names maybe, quotes do seem appropriate.) 
Applying that in the case of api.value.type, we'd have:

  %define api.value.type union-directive
  %define api.value.type union
  %define api.value.type variant
  %define api.value.type {int}
  %define api.value.type {variant}

I think that looks nice.  However, I suppose allowing quotes to be omitted 
would cause a parser conflict because, as I recall, we decided to allow 
the value to be omitted entirely.  Ugh.  Maybe we can deprecate omitted 
values in order to eventually support unquoted keyword values.