[boost] Re: Formal Review: FOREACH macro

From: Andrei Alexandrescu (See Website For Email) (SeeWebsiteForEmail_at_[hidden])
Date: 2005-05-09 00:47:20

Paul Mensonides wrote:
>>-----Original Message-----
>>From: boost-bounces_at_[hidden] 
>>[mailto:boost-bounces_at_[hidden]] On Behalf Of Andrei 
>>Alexandrescu (See Website For Email)
> 
>>Second, I disagree that the template engine and the 
>>preprocessor are similar. I see very very little similarity. 
>>The former is a mean pure functional language fostering 
>>pattern matching, recursion, and sporting knowledge and high 
>>integration with the non-templated part of C++.
> 
> What high integration are you referring to here?  I don't see much of a high
> integration between template metaprogramming and the rest of the language.  In
> fact, there is very little integration.  Instead, it's more like they coexist
> without interferring with each other, and communication is entirely one way.
> Even with the type system, the pattern-matching capabilities are limited to (in
> essence) syntactic matching rather than more general property matching.  You
> have to bend over backwards to do that (read: SFINAE).

It's not syntactic any day of the week. Not at *all*. Templates perform 
genuine recursive pattern matching. They feed on types and constants and 
offer types and constants back. I see good integration there. If, on the 
other hand, you want to discuss the limited amount of introspection C++ 
offers, that's a different subject.

> So, again, what high integration are you referring to?  What I see instead is a
> lot tricky techniques and a whole slew of specialized idioms to workaround the
> basic lack of real integration.  Don't get me wrong, I'm not condemning template
> metaprogramming or even specialized idioms and techniques.  Rather, the
> development of those idioms and techniques are laudable examples of people
> "thinking outside the box" to get something done given the tools that they have.
> The same applies to preprocessor metaprogramming.
> 
>>The 
>>computational model is known and powerful. In contrast, 
>>programming based on the token-oriented preprocessor uses 
>>arcane idioms and computations, which IMO just takes us back 
>>40 years.
> 
> What idioms are those?  This, BTW, from the perspective of a user, not library
> internals.  What is really the difference, idiomwise, between fold(list, state),
> fold<list, state>, and FOLD(list, state)?

I am referring to idioms that ask you to #define certain things and then 
invoke macros that will use them (or worse, include files that will use 
them!) and then #undef them, or that have you define files that rely on 
things like "I am iterating now through this file", all that comma 
handling, the necessarily long names, the dynamic binding (a historical 
mistake that keeps on coming again and again in PL design! yuck!) etc. 
IMHO those idioms' place is in programming language history books as 
"awkward first attempts".

Andrei