[Top][All Lists]

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

RE: Enhancement request: enabling Variant in C parsers

From: Victor Khomenko
Subject: RE: Enhancement request: enabling Variant in C parsers
Date: Thu, 25 Oct 2018 08:09:24 +0000

Hi Akim,

> That’s a matter of style, and I disagree.  Sure, it’s _needed_ for decltype on
> incoming arguments, but it’s also just the right thing.
> C was wrong, and is still wrong about arrays, pointers, and functions.
> Even Go people, who are clearly the real heirs of C, have departed from C
> on these three concerns.
> https://blog.golang.org/gos-declaration-syntax
> However, if you _really_ think it makes the example harder to understand, I
> will change it.  But they, don’t come up again with ostream_iterator :)

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. If you check 
cppreference website, they don't use trailing return types unless absolutely 

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

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

> > 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 ;-)

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. 


reply via email to

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