Proto for Boost mailing list page: Re: [proto] [phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)

Subject: Re: [proto] [phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-05-08 08:48:19

On Sunday, May 08, 2011 02:05:43 PM Eric Niebler wrote:
> 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, thanks for doing the dirty work here!

This is awesome! With the latest changes, Phoenix V3 now compiles than V2!
Wee!
Just about to fix everything ...