[cpp-threads] C++ committee meeting in Mont Tremblant

[Peter A. Buhr]

   I think there's a tad of misunderstanding in here, caused by the fact 
   that C++ is unusual in a particular way.

   Unlike most languages, of which parsers are just a tiny part of the 
   processing chain, C++ has a horrendously big complicated syntax. That 
   creates problems so wicked, that people who haven't actually tackled 
   them can hardly imagine them.

No misunderstanding here at all. I have been dealing with the syntax in C and
C++ for well over a decade and I'm intimately familiar with the hostile
syntactic environment of both languages. I have written a complete grammar for
C with heavy extensions (Cforall) and concurrent extensions for C++ (uC++). In
fact, the only "really" difficult part of the C/C++ syntax is the onion-wrapped
declarator syntax. The rest is reasonably straightforward.

The key point is that this old chestnut is an extremely weak reason for not
changing the language. If people suggest adding concepts that have no prior
syntactic or semantic presence in the language (like continuation passing or
lambda expressions or tuple spaces, etc.), than it is going to be difficult.
Alternative, if changes tie directly into existing syntactic and semantic
concepts in the language, than these changes are easy. If you want to make it
hard, it can be very difficult; if you make it easy, it is very very easy.

I would like to point out that all growing language go through major changes at
regular intervals. Ada83 was heavily modified for Ada95. Both Fortran and Cobol
have been heavily modified a couple of times with objects and vestiges of
concurrency. C was heavily modified with objects, generics and exceptions,
called C++.  Furthermore, the compiler people don't care as long as there are
no ambiguities; give them precise syntax and semantics and they can do
anything. Hence, C++ can be extended and the compiler people just want these
extensions to have precise meaning. So why are you people afraid to suggest
some clearly needed changes rather than dance around the problems?

   Makes sense?

No! It makes no sense to me at all. You have to come up with better reasons
than difficult syntax or the "will" of the standards committee to foster
change. The memory-model group is doing its job by pointing out hard reasons
why a memory model is necessary and getting on with a solution. Kudos to all of
them. So why are we not doing the same thing for rest of the concurrency
problems that have to be addressed? As Hans has pointed out, if you do
race-free concurrent programming you don't even need a memory model (or only a
weak model). Well, it turns out that 99% of all concurrent programs that
regular programmers need to write can be written using a race-free model and
these programs can achieve high-levels of performance and be written quickly
and with few errors. Is this not a useful goal? Given this observation, should
we not be examining high-level race-free mechanisms for C++ to achieve this
goal? I think we have to identify our audience, and target a solution for this
audience. The memory-model people have a very small audience doing very
precise, complex bits of concurrency at the ragged edge of performance.  We now
need to address the other large bulk of the concurrency audience and help them
do their job. And this group is significantly more than just the scientific
computation crowd, which is only a small percentage of all concurrent
programmers.