Re: Enhancement request: enabling Variant in C parsers

[Akim Demaille]

Hi!

> Le 25 oct. 2018 à 10:09, Victor Khomenko <address@hidden> a écrit :
> 
> Hi Akim,
> Well, when in Rome do as Romans do... This chapter is for C/C++ programmers, 
> not Go. Some of them are not even familiar with the new syntax.

Well, my point is that C++ has started to fix things.
You can you auto to leave the type on the right of
the introduced variable, you can use using to leave the
definition on the right too, auto -> to put things in
order, the lambdas have it right from the start, etc.
It’s a trend in the language itself.

> If you check cppreference website, they don’t use trailing return types 
> unless absolutely necessary.

Well, they did not throw away C++98 either, they document
all the standards, so their case is not comparable.


> On the philosophical note, I understand the reasoning in the blog you 
> referenced, but I think it misses several important points. In its time, C 
> blew other imperative languages out of the water, and one of the reasons was 
> its conciseness.

Nah.  It was just lucky to be part of the Unix world.
Likewise for Yacc and Make and Lex, etc.  Their success
is not really theirs.  Unix was the true gem, and its buddies
had a lot of luck.

Again, Go was made by these guys.  Not Richie, but Ken
Thompson is there too.


> Trailing return types require two extra tokens, "auto" and "->", so most 
> people will prefer the old syntax unless the trailing return type is the only 
> way to declare a function. Yes, the syntax can get ugly sometimes, e.g. the 
> blog uses a pointer to a function returning a pointer to a function as an 
> example. It’s ugly indeed. However, let's do a reality check: how many times 
> in your whole life did you need to declare a pointer to a function returning 
> a pointer to a function? 0? 1? 2?!! So a very marginal case is used to prove 
> a general point.

I have written ‘const char* argv[]’ tons of times,
and it always felt wrong.  I’ve had to write typedef
for function types, and it always looked wrong.



>>> * It is possible to use flex with C++ streams - flex has C++ interface, and 
>>> I
>> think C++ parsers should deploy C++ lexers.
>> 
>> Yes, but again, it’s a tutorial about Bison.  Flex in C++ is a moving target
>> (Hans, that’s your cue :-), and I’m not sure I should show too much about it.
> 
> It's not "too much", it's about replacing a C scanner by a C++ one - which I 
> guess more natural for C++ parsers. BTW, the C++ interface in flex was around 
> for a while, and not that unstable - at least some of my C++ scanners are 
> older than a decade ago and they still compile…

Well, I guess YMMV, but the interface was changed when
they decided to move from pointers to references for the
streams.  Without any compatibility plan (an alias would
have solved the problem).  It was messy and painful to adjust
to this change, and worse to be compatible with several
versions of Flex.

https://gitlab.lrde.epita.fr/vcsn/vcsn/commit/dcdf2b3cae7353d99520448a7b22a4334a72bc5d

And then you have to copy and edit flex-lexer.hh to tune it
to your use case.

I don’t know how you use Flex in C++, but the cost I have
in my own projects to do so did not encourage me to show
that in a simple example.

As a matter of fact, it’s already been reported here that some
users of Bison in C++ have quit using Flex, and decided to use
<regex> and deal with the scanner by themselves.


>>> Another thought for future: You mentioned that AST with location
>> information is in fact the mainstream, but this is never explained in the
>> manual!
>> 
>> We don’t speak much of ASTs either :)  I don’t think that’s our job here.
>> Don’t you agree?
> 
> So you assume users already know that trick with locations? Wow!!! You must 
> have some really brilliant users, I feel so inadequate ;-)

There must be some misunderstanding here.  The manual is about
Bison, it’s not an introductory course to compiler construction.
That’s what I meant.  So, yet, ASTs are mentioned a couple of
times, but it’s out of the scope of the manual to get into the
details.

IMHO.


> Well, seriously, a bison parser interfaces the world in two places: On the 
> low end, it uses a scanner, often a flex one. On the opposite end, it usually 
> generates an AST for further processing. I believe these two interfaces 
> deserve to be covered in some detail, otherwise users will be reinventing the 
> wheel. (IMHO)

What do you suggest?  That we provide an example that builds
an ast?

Actually, I discovered _last week_ that there’s a Wikipedia
page for Bison.  And I don’t like it.  Its example is precisely
building an AST, and I think that that’s wrong.  Bison is
completely lost among lengthy details on dealing with the AST.

It could make sense to keep this example as an advance example,
but that example, being the only one, is wrong.