> On 19 Dec 2018, at 15:38, Frank Heckenbach <f.heckenb...@fh-soft.de> wrote: > > Hans Åberg wrote: > >>> By default, I keep recipients (list) and CCs (Akim) as is. >> >> With a reply to all, it would come out right. > > Depends on what you consider right. It's a mailing list. Those who > write here are expected to read via the list (subscription or > archive; I know you do) or take their own measures (Reply-To or CC). > With "reply to all", I get all of your mails twice, doesn't seem > right to me (though only slightly annoying these days, as opposed to > 20 years ago when every KB of internet data cost a fortune ;).
That can be changed in you list subscription. The emails I get have both your address and bug-bison, so you perhaps already get two copies anyway on the reply-alls. >>> If you >>> want a private copy, set a Reply-To. >> >> Those are generally bad. > > I don't agree. Some years ago there was a somewhat famous rant > against them, but it was full of BS and misunderstandings. > > Or you can set a CC to yourself if you wish. I simply did not know why you had this funny cc'ing to some, but not to me. Don't worry about it. >> I might not notice your posts, so do as you wish. > > Honestly, you *not* noticing my posts is one of my smallest worries. ;) Well, I apologize for replying to your email, but it seemed directed to be. >>>>>> Actually, I pass the semantic value through a class object to >>>>>> which the lexer function belongs, so the extra arguments are not >>>>>> needed. So I must think more about this. >>>>> >>>>> FWIW, my lexer function is also part of a "driver" object, but I >>>>> don't think that's relevant here. Maybe you think of the "%param" >>>>> arguments, but it's not about those. >>>> >>>> No, I use the Flex C++ parser right now, which for some reason >>>> requires an empty argument, so this works without patching the >>>> header, that is, until they decided to bomb it in 2.6 and later. >>> >>> I don't use flex anymore, and never used flex C++, so I don't know >>> about that. But again, that's unrelated to the current proposal. >> >> It was in response to your comment. > > Which was in response to your comment about some mysterious "extra > arguments". I do not use %param, don't worry about the other. >> There might be a problem with the Bison variant if one in the >> lexer returns an object of another type that the token type, and >> expect a conversion. > > There is no conversion, and in most cases, there couldn't be any > when types are too different; but even if types are similar enough > that a safe automatic conversion would be possible, say char to int, > I know of no variant or union that would do so. That's not specific > to Bison's variant. > > So such a mismatch is an error. The only difference is how this > error is handled. std::variant throws an exception on usage; Bison's > variant so far basically makes it UB (which is a valid answer; many > things in C++ are UB), the current proposal would report an error on > construction already, so slightly better than std::variant (in case > the mismatching value is silently discarded). Two lookup table variations: The values are stored, with the token value, as a pointer to a base class, or as variants.
