Re: [boost] [preprocessor] Sequences vs. All Other Data Structures

Subject: Re: [boost] [preprocessor] Sequences vs. All Other Data Structures
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-04-23 19:19:28

On Mon, 23 Apr 2012 14:08:02 -0700, paul Fultz wrote:

>>>  I understand that Chaos won't implement workarounds. I was thinking
>> more
>>>  of forking chaos, and trying to implement it in msvc. Would that be a
>>>  possibility? And with your knowledge of Chaos's implementation and
>>>  msvc limitations, do you even think that it would even be remotely
>>>  feasible?
>> 
>> I don't think it's feasible.  You *might* be able to emulate the base
>> interface over a completely separate (and much larger) implementation. 
>> However, you won't be able to emulate the extensibility model.  For
>> example, one of the defining things about Chaos is its ability to
>> generalize recursion (not referring to the sequence tricks that I
>> started this thread with).
> 
> Well, actually this code here will work in MSVC:
> 
> #include <boost\preprocessor.hpp>
> #define PP_EMPTY(...)
> #define PP_EXPAND(...) __VA_ARGS__
> #define PP_WHEN(x) BOOST_PP_IF(x, PP_EXPAND, PP_EMPTY) #define
> PP_DEFER(m) m PP_EMPTY()
> #define PP_OBSTRUCT(m) m PP_EMPTY PP_EMPTY()()
> 
> #define EVAL(...) \
> Â Â Â  A(A(A(__VA_ARGS__))) \
> Â Â Â  /**/
> #define A(...) B(B(B(__VA_ARGS__)))
> #define B(...) C(C(C(__VA_ARGS__)))
> #define C(...) D(D(D(__VA_ARGS__)))
> #define D(...) E(E(E(__VA_ARGS__)))
> #define E(...) F(F(F(__VA_ARGS__)))
> #define F(...) __VA_ARGS__
> 
> #define REPEAT(count, macro, ...) \
> Â Â Â  PP_WHEN(count)( \
> Â Â Â Â Â Â Â  REPEAT_INDIRECT PP_OBSTRUCT()()( \
> Â Â Â Â Â Â Â Â Â Â Â  BOOST_PP_DEC(count), macro, __VA_ARGS__ \
> Â Â Â Â Â Â Â  ) \
> Â Â Â Â Â Â Â  macro PP_OBSTRUCT()( \
> Â Â Â Â Â Â Â Â Â Â Â  BOOST_PP_DEC(count), __VA_ARGS__ \
> Â Â Â Â Â Â Â  ) \
> Â Â Â  ) \
> Â Â Â  /**/
> #define REPEAT_INDIRECT() REPEAT
> 
> #define PARAM(n, ...) BOOST_PP_COMMA_IF(n) __VA_ARGS__ ## n
> 
> EVAL( REPEAT(100, PARAM, class T) ) // class T0, class T1, ... class T99
> 
> #define FIXED(n, ...) BOOST_PP_COMMA_IF(n) __VA_ARGS__ #define TTP(n,
> ...) \
> Â Â Â  BOOST_PP_COMMA_IF(n) \
> Â Â Â Â Â Â Â  template<REPEAT(BOOST_PP_INC(n), FIXED, class)> class
> Â Â Â Â Â Â Â  __VA_ARGS__ ## n \
> Â Â Â  /**/
> 
> EVAL( REPEAT(3, TTP, T) )
> // template<class> class T0,
> // template<class, class> class T1,
> // template<class, class, class> class T2
> 
> Of course, I had to add extra level of scans in the EVAL macro,
> otherwise it would stop at 62 repetitions. This will now handle up to
> 182 repetitions. Of course, a more efficient approach is done in Chaos,
> but perhaps the recursion backend could be implemented in MSVC, but it
> will be slower, which is ok since I don't develop on MSVC, I just need
> it to build on MSVC. I will look into this further.

I actually looked at doing something like this with Chaos, but there is no 
way to stop the exponential number of scans.

That's a severe problem, but even if that wasn't, the model is different 
as the above is essentially just an uncontrolled continuation machine.  
Call-and-return semantics are destroyed as there is no real notion of 
yielding a result *now* unless you make A reeentrant, but then you end up 
getting a *way* higher number of scans--either because you have say 16 
separate sets like the above or you have the above go at least 32 "deep."  
For example, when two things need to occur during the exact same scan 
because the next scan is going to invoke something that involves both 
results (anything with half-open parentheses, for sure, but even something 
stuff like conditionals).  This, in turns, leads to continuations rather 
than call-and-return semantics, but then one should just make a 
continuation machine ala the one in Chaos or Vesa's original one in Chaos' 
sister project Order.  In the right context, continuations are not 
necessarily a bad thing, but they are definitely a different extensibility 
model.

Regards,
Paul Mensonides