Re: [boost] Boost.Preprocessor: A prototype pow(N,2) max direct iteration WHILE.

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-14 18:34:22

"Vesa Karvonen" <vesa_karvonen_at_[hidden]> writes:

> David Abrahams:
>>FWIW, while in my opinion this is theoretically interesting work,
>
> BTW, the same "acceleration" technique can be used with templates to
> overcome template recursion depth limitations. Probably most people
> know about it already, though I haven't explicitly checked. 
> (Plain unrolling is not as effective: Theta(k*n) < Theta(pow(k,n)).)

Well, if I understand your suggestion correctly, it's one thing I
thought of.  Basically you're doing "tree unrolling" instead of
"linear unrolling", right?  In the TMP case you don't have the
advantage of auto-detecting the depth limit, though ;-)

>>I can't imagine a case where the limit might cause a problem for my
>>code.  In other words, the PP library works great for me, and nobody
>>should feel pressure to lift its arbitrary limits on my account.
>
> IMO, it is not a very good argument to say that more powerful tools
> are unnecessary

I am not making that argument.  I am just trying to say that I think
the library is already serving its users well.  One argument I *would*
make is that if anyone is going to invest more time in it, the
introductory overview Edward Diener wants would make more of a
difference than lifting this limitation.

> , because a specific person (or even a set of persons) does not find
> them useful. It must have been said a million times before and
> probably every time it has been shown to be wrong (in time). A much
> better argument would be that the same effect can be had with only
> minimal overhead compared to the proposed tool with existing tools,
> thus making the proposed tool mostly unnecessary.

But I'm not saying that.

> There are a few good practical reasons why a more powerful WHILE may
> not be very useful. One good reason is that most preprocessors are
> rather slow. This means that even if we could theoretically use the
> preprocessor for non-trivial compile time computation, it may be too
> slow to be practical. Another good reason is that preprocessor code
> is not necessarily very readable, so many interesting things may
> require too much programming time. Essentially,
>
> "Why program by hand in 5 days what you can spend 5 years of your life automating?" -- Terence Parr
>
> (, but with the opposite conclusion.)

Well, yeah.  However, I think for some things the *usage* of that code
can be more readable than TMP.  Your state machine below is one
good example.

> However, I think that there are many useful things that could
> potentially be done using the preprocessor if the arbitrary limits
> on iteration would be removed and performance would be
> acceptable. Consider, for example, the state machine example of the
> MPL paper. A state machine generator using template metaprogramming
> techniques is essentially limited to having to specify functions as
> the actions. This can be partially circumvented by using a lambda
> library, but the solution is not perfect.

No, not hardly.

> A distinct possibility would be to use the preprocessor to generate
> the transition function. What makes this interesting is that then we
> could pass in straight C++ blocks as actions. 

Ever thought about writing Yacc with just the preprocessor (<wink>, I
think)?

> Consider the following pseudo-code snippet, which is a start of the

<snip>

Nice.

> Similar things can certainly be done with various templates
> techniques. However, when it comes to passing arbitrary C++ code to
> the generator, preprocessor macros have certain advantages. 

Lots.

> Now, the above example can probably be done without a more powerful
> WHILE, but many generators / mini compilers may do substantially
> more computation. Theoretically, the preprocessor could be used for
> making a parser generator 

I guess you have thought about making Yacc.  You're a few steps ahead
of me, friend.

> that could have an advantage compared to Spirit due to syntactical
> issues. The main practical problems would be the difficult of
> implementation and compile-time performance (which is exactly the
> same as with template techniques, but often worse).

Yep.

> Another possible direction for program generators would be to take a
> middle road: use preprocessor to define the input syntax and
> generate code skeleton (switch case statement), then use template
> metaprogramming or even run-time code to compute the transition
> tables. This kind of an approach would make it possible to get a
> very nice syntax for specifying many kinds of program generators
> (and in many cases the overhead of transition table generation is
> not important).

To be sure, the world of C++ metaprogramming is vast and mostly
unexplored.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution