2) For a macro library, do we still need to have a BOOST_ prefix or could I just keep the CHAOS_PP_ prefix? I cannot use BOOST_PP_ without bending over backwards to find contrived names for everything, and the namespace of brief names beginning with BOOST_ is tiny--especially when a library provides hundreds of user-interface (i.e. not implementation detail macros).
Perhaps `BOOST_CPP_` could be used.
3) For those of you familiar with Chaos, how many actually use the lambda mechanism? I've been internally debating whether to preserve it for years. It complicates things. The other thing is whether C90/C++98 should be supported (i.e. variadic/placemarker-less mode). Currently, Chaos does support these, and the lack of them in some cases leads to interesting techniques (which is half the reason for Chaos in first place).
First, I think it should just support C99/C++11, for older preprocessors Boost PP can be used. I never use the lambda expression because they can be very slow, but I thought it would be nice to support some generic "invokable" expressions so perhaps supporting a form of bind for macros, like this: CHAOS_PP_EXPR(CHAOS_PP_REPEAT(3, CHAOS_PP_BIND(CHAOS_PP_CAT, T, _1)) // T0 T1 T2 As well as supporting lambda or even user-defined invokable expressions. Ultimately, bind would just be implemented as this(Yes I know chaos already has a bind macro): #define CHAOS_PP_BIND(m, ...) (CHAOS_PP_BIND)(m, __VA_ARGS__) And then the invoker would call the appropriate macro using the same mechanism used for generics. #define CHAOS_PP_GENERIC(m, e) CHAOS_PP_CAT(CHAOS_PP_CAT(CHAOS_PP_TYPEOF(e), _), m) #define CHAOS_IP_INVOKER_0(e) CHAOS_PP_MACRO_INVOKE #define CHAOS_IP_INVOKER_1(e) CHAOS_PP_GENERIC(INVOKE, e) #define CHAOS_PP_INVOKER(e) CHAOS_PP_CAT(CHAOS_IP_INVOKER_, CHAOS_PP_IS_VARIADIC(e))(e) #define CHAOS_PP_MACRO_INVOKE() CHAOS_IP_MACRO_INVOKE #define CHAOS_IP_MACRO_INVOKE(s, m, ...) CHAOS_PP_EXPR_S(s)(m CHAOS_PP_OBSTRUCT()(__VA_ARGS__)) So for the expression `(CHAOS_PP_BIND)(...)` it will call `CHAOS_PP_BIND_INVOKE`, and if lambda expressions were "typed" as well like `(CHAOS_PP_LAMBDA)(...)`, then it would call `CHAOS_PP_LAMBDA_INVOKE`. So instead of trampolining in higher-order macros, it would just call the `INVOKER` instead: #define CHAOS_PP_DELINEATE(n, sep, m) CHAOS_PP_DELINEATE_S(CHAOS_PP_STATE(), n, sep, m) #define CHAOS_PP_DELINEATE_S(s, n, sep, m) DETAIL_CHAOS_PP_DELINEATE_U(s, n, sep, m, CHAOS_PP_INVOKER(m)) #define DETAIL_CHAOS_PP_DELINEATE_U(s, n, sep, m, _m) \ DETAIL_CHAOS_PP_DELINEATE_I(CHAOS_PP_OBSTRUCT(), CHAOS_PP_INC(s), CHAOS_PP_DEC(n), sep, m, _m) #define DETAIL_CHAOS_PP_DELINEATE_INDIRECT() DETAIL_CHAOS_PP_DELINEATE_U #define DETAIL_CHAOS_PP_DELINEATE_I(_, s, n, sep, m, _m) \ CHAOS_PP_WHEN _(n) \ ( \ CHAOS_PP_EXPR_S _(s)(DETAIL_CHAOS_PP_DELINEATE_INDIRECT _()(s, n, sep, m, _m) sep _()) \ ) \ _m()(s, m, s, n) I don't know what anyone else thinks of that, as well.
http://chaos-pp.cvs.sourceforge.net/viewvc/chaos-pp/chaos-pp/built-docs/ primary.html
There are a lot of bits of sample code throughout the documentation, though the topical documentation incomplete.
The documentation is really missing explanations on recursion steps, and parametric resumptions. I never really fully understood what those additional repetition macros did. Thanks, Paul