Re: Enhancement request: enabling Variant in C parsers

[Hans Åberg]

> On 25 Aug 2018, at 08:10, Akim Demaille <address@hidden> wrote:
> 
>> Le 23 août 2018 à 14:09, Hans Åberg <address@hidden> a écrit :
>> 
>> 
>>> On 23 Aug 2018, at 13:14, Akim Demaille <address@hidden> wrote:
>>> 
>>>> Le 23 août 2018 à 10:34, Hans Åberg <address@hidden> a écrit :
>>>> 
>>>> This style with local.mk perhaps comes from an age where Automake was not 
>>>> as smart. I use a Makefile.am.
>>> 
>>> Totally unrelated.  I use local.mk (should be local.am) because it’s
>>> included from the top-level Makefile.am.  There’s a single Makefile
>>> in the end, and that’s on purpose.  I do not want recursive Makefiles.
>> 
>> Why not? I use local.mk, too, in simple cases.
> 
> Look for « recursive make considered harmful », there are tons of
> pages about that.

I use it to cut build times by compiling in a subdirectory, then one can move 
to the root directory to check that it is consistent. There are also hits for 
“non-recursive make considered harmful”. :-)

>>>> so perhaps it should be replaced with a 
>>>> %semantic-type {...}
>>>> or something.
>>> 
>>> ‘something’ is '%define api.value.type'.
>> 
>> So use it in the example, simply for illustration of the feature.
> 
> The example uses it, for variants.

Sorry I was confused by the untyped parser and the "define".

But it strikes me that one possibility with std::variant might be to allow 
non-terminals to have multiple types, though I do not know whether it is 
useful. After the parse, one would then check the possible values one got.