[Top][All Lists]

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

Re: symbol_type::token () removed?

From: Wolfgang Thaller
Subject: Re: symbol_type::token () removed?
Date: Thu, 02 Jan 2020 10:20:12 +0100
User-agent: Evolution 3.34.1-2

On Thu, 2020-01-02 at 08:27 +0100, Akim Demaille wrote:
> About a year ago, I wrote to you
> > > The thing is that I don't know how people are using these types:
> > > they do things that are not documented, and as such, are not
> > > considered part of the contract.
> and that's another instance of that pattern.

Obviously. Basically this is another "I think this should be part of
the contract" feature request.

> which gives me the impression that the real use case would be
> something like
> assert(t == token::make_INTLIT(12345))
> WDYT?  Hum.  That would require operator==, which would generate a
> lot
> of code.  And it would require the value types to support ==, which
> so
> far we do not require.

It could be another %define option, and then static_assert the presence
of operator== for the value types. Or maybe it would be possible to
SFINAE it, so that it's available if the indidual operator== are
available? Requiring it for all type is sure to break things for some
people (or make them write dummy operator== implementations).
But anyway, I'd consider that a luxury feature.

> The reason I was very happy to get rid of it is that it's kind of
> big:

Sounds like a good argument.

> Have you given a shot at api.token.raw?  In that case
> symbol_type::token()
> would be really thin: it would just return 'type'.

Not yet. I'll have to wait until bison 3.5 is everywhere until I get to
use it, but it looks good.
In fact, is there any reason to ever *not* use token.api.raw when I'm
using token.api.constructor? It looks like the symbol_type constructor
will (rightly) forbid me from just sticking in raw char values.
Should token.api.raw be the default for token.api.constructor? Or at
least strongly suggested by the docs?

I'll definitely switch to token.api.raw once I'm ready to require bison
3.5. But then, I'd still be using undocumented functions for my unit

I *should* also be testing sym.location, but currently I don't.

So that's my reduced feature request: document and declare those two
things (or some variant of them or wrapper for them) part of the public
contract for token.api.constructor (at least when used with

> > P.S.: Keep up the good work, bison is my favorite way of parsing
> > things
> > using C++....
> Thanks a lot for saying :)

Needs to be said now and then. Had to use ANTLR at work, no time for a
complete rewrite using bison :-(. Feels like Java. Insists on building
a parse tree where I don't need one, which I then need to take apart
again to build the data structure that I do need. Keeps converting to
UTF-16 and back. Slow. Bison just does what I want, and does it well.



reply via email to

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