This library is possibly the most ambitious example yet of a category of libraries that, essentially, implement core language features using library constructs. Other examples include:
- Matt Calabrese’s Boost.Generic prototype
- Paul Fultz’s recent implementation of “pythy syntax”
I’m posting about the library here for two reasons. First, I think it’s cool and deserves a review from you (see my posting on the review period extension for details). Second, and primarily, I wonder if libraries like this one can help us over the great obstacle we face in standardizing new core language features. I’m referring here to the “lack-of-an-implementation” problem.
You see, for a number of good reasons, the committee is usually supposed to “standardize existing practice.” That’s how we ensure what we standardize is useful, usable, and implementable. We don’t always adhere to this policy, but core proposals without an implementation typically—and justifiably—face a much higher level of scrutiny and often a great deal of resistance from committee members as a matter of principle.
When it comes to core language features, this policy usually requires an expert on the details of an existing C++ compiler to devote significant time and energy to implementing the new feature. Since existing experts are few, and their time is dear, this can be an expensive proposition even for “simple” features. This is all on top of the time and energy one must devote to writing, defending, and refining the standarization proposal. In practice, the very few experts with time to implement any new features are using all of it to implement their own proposals. So how is anyone else supposed to get a new core language feature accepted into the standard?
It would go a long way if a library implementation could suffice as “implementation experience” for the purposes of standardizing a core language feature. One could, after all, write the standard proposal in terms of a mechanical transformation from the proposed core syntax into corresponding library constructs. Of course how much this proves depends on the library constructs having the ability to faithfully reproduce the desired functionality. Also, it would likely not serve as a complete test. For example, parsability of the proposed core syntax might have to be verified by hand. To my knowledge we have never tested this approach in the committee, so I don’t know if it will fly.
And then there’s the big-picture language design question. One can imagine C++ having been designed with enough intrinsic metaprogramming capability to allow nearly every new “core” feature to be fully and portably implemented by the language’s users. This has been tried before (see Common Lisp macros) with mixed success. The primary danger in lowering the barrier to language extension is that everyone extends the language in his own direction, and there’s no longer any lingua franca, so everyone’s code becomes unreadable. The counterargument is that people will find ways to do language extension by hook or by crook, leading to techniques like preprocessor and template metaprogramming, which are inefficient, ugly, and fragile compared to their first-class counterparts.
I’ve got no grand conclusion for this posting, other than to invite your input on the topics raised. Thanks for reading!