Re: [boost] [Preprocessor] Adding variadic macros support

Subject: Re: [boost] [Preprocessor] Adding variadic macros support
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2010-11-29 06:55:48

On Sun, 28 Nov 2010 21:09:34 -0800, Jeffrey Lee Hellrung, Jr. wrote:

> I believe the now-impossible-to-find "Avalanche Preprocessor library"
> that that a user posted a link to some time back used a somewhat
> different syntax for lambdas.  Recalling strictly from memory, it would
> look something like
> 
> CHAOS_PP_EXPR( CHAOS_PP_ENUM(
>      5,
>      CHAOS_PP_BIND( CHAOS_PP_PRIMITIVE_CAT_, ( class T ), 1 )
>      CHAOS_PP_BIND( CHAOS_PP_WHEN_, 1, CHAOS_PP_BIND( CHAOS_PP_CAT_, ( =
> T ), CHAOS_PP_BIND( CHAOS_PP_DEC_, 1 ) ) )
> 
> In other words, there was some very heavily-used CHAOS_PP_BIND-like
> macro that essentially initiated a lambda sequence, which accepted the
> macro to bind followed by the arguments to bind.  Arguments appearing as
> numerals (1, 2, etc.) were placeholders, while arguments appearing in
> parantheses were literals.  I don't remember much of the syntax,
> semantics, or mechanics past that.  What I wrote above is probably not
> considered preferable to using the existing Chaos lambda syntax, but
> maybe some combination of these ideas could be massaged into a better
> syntax with faster compile times, given willing investigative souls.

The lambda expressions in Chaos are made up of a relatively few 
primitives.  All (or, at least, almost all) library primitives define 
lambda bindings such as the following:

#define CAT(a, ...) PRIMITIVE_CAT(a, __VA_ARGS__)
#define CAT_ID() CAT
#define CAT_ LAMBDA(CAT_ID)()

The LAMBDA macro (as well as the other lambda operators such as ARG(1), 
ARG(2), etc.) expand to expressions such as the following for LAMBDA
(CAT_ID)()

(,,,,, (etc) ,,,, 0xLAMBDA, (CAT_ID))()

The parser than has a "horizontal" limit on how far over it can parse an 
expression (the current limit is 50, so there is about 50 commas in the 
above).  Otherwise, the parser has no (practical) limit on depth.  It 
parses and substitutes general expressions.

The main problem is a general problem with preprocessor metaprogramming.  
The parser cannot "get past" some input.  You cannot safely use token-
pasting against arbitrary input, as that leads to undefined behavior.  
Even if it didn't, you still couldn't get past other stuff like 
operators.  E.g.

CHAOS_PP_EXPR(CHAOS_PP_SEQ_FOR_EACH(
    (CHAOS_PP_ARG(1) + CHAOS_PP_ARG(2)),
    (a, b)(x, y)(p, q)
))

This yields garbage output because their is no way for the parser to see 
past the '+' opreator to find the ARG(2).

-Paul