RE: [boost] PP lambda?

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2003-04-10 21:44:11

Paul Mensonides wrote:
> Hi Aleksey,

Hi Paul,

> The major problem with this is making it work on buggy preprocessors
> -- which is either not possible or so difficult that it wouldn't be 
> worth it.

That's OK at least with me in terms of that I am more interested in a 
long-term outcome of the PP library's evolution. Also, it's always 
easier to approach vendors when you have something public you can point
them to and say "this doesn't work". And then there is always Wave (if
I haven't mentioned it yet, I am really excited about this work!).

> 
> However...
> 
> I'm working on a "strict" pp-lib that will be complete in 1-2 weeks.
> This version of the pp-lib contains absolutely no hacks and therefore
> gives me a great deal more freedom in what I can accomplish.  This 
> "strict" version is already several magnitudes more powerful than the 
> current CVS pp-lib--even without lambda.  As far as lambda is 
> concerned, the facility _already_ exists in the strict pp-lib.

That's great to hear!

>
> There are three caveats:  first, only two preprocessors, AFAIK, can 
> handle the strict pp-lib:  wave and gcc.  Not even EDG can handle it 
> (and I'm not referring to speed). Second, the strict pp-lib is not 
> compatible with the CVS pp-lib in many ways, and compatibility is not 
> possible.

That's perfectly fine IMO.

> Third, the parametric lambda facility is implemented with variadics 
> and placemarkers, which are part of C99, but not C++.  This was a 
> deliberate design decision as the syntax is much cleaner for the user 
> then the non-variadic version was that I had implemented previously. 

That's understandable too; these extensions are already available in 
many contemporary compilers anyway.

> For your example above, it looks something like this (and I'm using
> a different macro prefix so that the strict pp-lib can co-exist with 
> the CVS pp-lib):
> 
> CHAOS_PP_EXPR(CHAOS_PP_REPEAT(
>     5
>   , ( CHAOS_PP_CAT_( (1), (0) ), =, (0) )
>   , int x
> ))

Not bad at all. Can we somehow get rid of the extra commas and
have the "canonical" placeholder names, e.g.

CHAOS_PP_EXPR(CHAOS_PP_REPEAT(
      5
    , ( CHAOS_PP_CAT_(_1, _0) = _0 )
    , int x
    ))

?

> BTW, the CHAOS_PP_EXPR above has nothing to do with the lambda 
> expression in parameter 2.  That is part of a recursive abstraction 
> that is, by itself, several orders of magnitude more powerful than 
> the CVS pp-lib.  E.g. the CVS pp-lib supports three dimensions of 
> repetition with BOOST_PP_REPEAT, and requires over 256 macros to 
> implement each one.  The strict pp-lib needs only about **three or 
> four** macros to support up to 512 dimensions with a maximum of 512 
> total repetitions.  The same is true for WHILE, FOR, ENUM, various 
> types of FOLD_RIGHT and FOLD_LEFT for different data structures, 
> and even the FOR_EACH_PRODUCT algorithms.  Basically, you have 
> full-fledged, generalized recursion and full algorithmic support.

Way too cool! 

Somewhat out-of-line thought - how about BOOST_P2 for the new prefix?

> 
> The major purpose of the "strict" pp-lib is to show what _could/can_ 
> be done if preprocessors would get their act together and to give me
> a clean implementation to use as a reference implementation.  The 
> "strict" pp-lib literally blows the CVS pp-lib out of the water.
> 
> So, the answer to the question, "can it be done?", is "yes." 

That's really good news. 

Do you think it's possible to archive cleaner syntax for it within C99, 
though? The one you cited is still a little bit too contrived, IMO - too
many brackets/extra punctuation to be easily readable.

> Can it be done on buggy preprocessors, particularly VC++ and MWCW? 
> Unlikely.  Can it be done without variadic macros?  Yes, but it makes 
> for ugly, hard-to-read lambda expressions, which make it much easier 
> just to define the target macro instead.

I wonder how the latter ones look like.

Thanks for all the insight,
Aleksey