[boost] [proto][phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)

Subject: [boost] [proto][phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)
From: Eric Niebler (eric_at_[hidden])
Date: 2011-05-08 08:05:43

On 5/2/2011 6:18 PM, Thomas Heller wrote:
> On Mon, May 2, 2011 at 12:54 PM, Eric Niebler <eric.niebler_at_[hidden]> wrote:
>> Phoenix is changing the following fundamental constants:
>>
>>  BOOST_PROTO_MAX_ARITY
>>  BOOST_MPL_LIMIT_METAFUNCTION_ARITY
>>  BOOST_PROTO_MAX_LOGICAL_ARITY
>>  BOOST_RESULT_OF_NUM_ARGS
>>
>> IMO, Phoenix shouldn't be touching these. It should work as best it can
>> with the default values. Users who are so inclined can change them.
> 
> Eric,
> This problem is well known. As of now I have no clue how to fix it properly.
<snip>

The Proto pre-preprocessing work on trunk has progressed to the point
where compiling with all the arities at 10 now compiles *faster* than
unpreprocessed Proto with the arities at 5. So I've bumped everything to 10.

A few things:

1) Phoenix is now broken. My Proto work involved pruning some
unnecessary headers, and Phoenix isn't including everything it needs.
Thomas, I'll leave this for you to fix.

2) Phoenix is actually setting Proto's max arity to 11, not to 10. I
think this is unnecessary. Locally, I un-broke Phoenix and ran its tests
with 10, and only one test broke. That was due to a bug in Phoenix. I'm
attaching a patch for that.

3) After the patch is applied, Phoenix should be changed such that it
includes proto_fwd.hpp and then acts accordingly based on the values of
the constants. IMO, that should mean graceful degradation of behavior
with lower arities, until a point such that Phoenix cannot function at
all, in which case it should #error out.

4) Phoenix no longer needs to change BOOST_MPL_LIMIT_METAFUNCTION_ARITY
and BOOST_RESULT_OF_NUM_ARGS, but BOOST_RESULT_OF_NUM_ARGS should be
given the same treatment as (3).

5) MSM do the same.

My pre-preprocessing work continues, and all EDSLs that use Proto will
benefit from faster compiles. I'd like to thank Hartmut for his work on
Wave and Thomas for getting me set up.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com