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

Subject: Re: [proto] [boost] [phoenix][msm] proto limits increased to 10, phoenix broken on trunk (was: [phoenix] not playing nice with other libs)
From: Hartmut Kaiser (hartmut.kaiser_at_[hidden])
Date: 2011-05-08 12:08:35

> 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.

I'm glad you did the changes because this improves compile times for everybody using Proto! This will further lessen the burden for people currently scared off.

Just a question: what's your rationale of limiting the generated pp headers to an arity of 10? 
MPL and Phoenix have it set up for higher arities as well (as you probably know).

Regards Hartmut
---------------
http://boost-spirit.com