[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: Support emplace with multiple arguments

From: Askar Safin
Subject: Re[2]: Support emplace with multiple arguments
Date: Tue, 11 Dec 2018 00:44:31 +0300

>But do you actually use this?
Well, first of all I usually use bison with flex. And I use C++ (i. e. 
%skeleton "lalr1.cc"). And I use "%define api.value.type variant".

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?), 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)
* pa-0.1 (small proof assistant)
* scheme-in-cpp-interpreter (small scheme interpreter)

All them are here: https://github.com/safinaskar .

I don't need to pass multiple arguments to build/emplace, 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.

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

>commit 951c88c1d471346f220233ea8839ec42a188062f
The commit displays wrong at 
http://lists.gnu.org/archive/html/bug-bison/2018-12/msg00021.html (but displays 
properly in my mailbox). The lines are unnecessary wrapped and this makes patch 
invalid. It seems mailman is misconfigured. I think the right solution is to 
preserve original line breaks and perform word wrap using CSS only. I think 
this is how bugs.debian.org did it recently, look here for example: 

Askar Safin

reply via email to

[Prev in Thread] Current Thread [Next in Thread]