Re: Support emplace with multiple arguments

[Akim Demaille]

> Le 10 déc. 2018 à 22:44, Askar Safin <address@hidden> a écrit :
> 
>> But do you actually use this?
> 
> Second, I don't know how to use bison (and flex) the right way. There is a 
> lot of things about bison (and flex), which I don't want to learn now, and 
> which I postponed to distant future. For example, how to use locations, how I 
> should construct semantics values in flex source files (should I use 
> build<...>? or make_ID?),

I think I stated clearly that I recommend make_<SYMBOL>.

> how to report errors, etc. So I just stick with some solutions which seem to 
> work. Say, calling build<...> from flex source seems to work. Okey, let's go 
> with it. When I start new project using bison and flex, I just copy-paste 
> from some existing bison/flex project. Without fully understanding meaning of 
> all this directives (I simply don't remember why I placed all them at the 
> first place). I wish some day I will re-read bison and flex manual and start 
> to use this projects the right way.
> 
> Yes, I use build<...>. Because it seems to work. Here is my projects using 
> bison and flex:
> 
> * js-in-cpp-interpreter (well, this is small js interpreter)

Since you appear to be willing to spend some time on Bison right now, maybe you 
could have at shot at trying api.token.constructor and report your experience.


> I don't need to pass multiple arguments to build/emplace,

So please, don't ask for features you don't plan to use.  I have enough to do 
without that.

> because I work with simple values such as std::string and int. So, well, yes, 
> I don't need this parameter pack feature. But I wonder why you added this 
> "emplace" method in the first place? Why not stick with "build"? If the only 
> reason was to be idiomatic, then, well, "emplace" should accept parameter 
> pack, because this is what, say, vector::emplace_back does.

Yes, I changed it because C++11 introduced 'emplace' that did not exist when 
variants where added to Bison.  So yes, if feels right to do that.  If someone 
needs the variadic emplace then I'm fine adding it, because, yes, I agree it is 
right.

Yet, I would be happy to save my spare time to do things I enjoy, or are 
useful.  Over the years Bison learned new tricks, such as 
api.token.constructor, but has to maintain the previous ones, since some people 
might not have made the move (three examples above).  However, that's not a 
reason to improve the feature that seems inferior to other newer alternatives.  
That's why I did not plan to extend 'emplace/build' unless there's a clear sign 
that they help.

So, again, please, don't suggest that *I* work on something you don't care 
about.


>> Don't you use api.token.constructor instead?
> I didn't know about it before. But now I checked it, and I don't like it. 
> Because it means I should give names to all my punctuation chars. Thus flex 
> source became bigger. And bison source became bigger, too, because I need to 
> declare all this punctuation chars in it. And I need to keep this punctuation 
> list in bison and flex in sync.

I personally strongly dislike that tokens are not named.  Because of that Bison 
is obliged to maintain two levels of token numbers and an indirection in the 
middle that wastes space and time for each call to yylex.

Yet I agree there is something wrong in the current model that requires too 
much work, something should be done eventually.