Re: [proto] expanding Proto's library of callables
Eric Niebler wrote: > On 12/28/2010 11:43 AM, Thomas Heller wrote: >> Eric Niebler wrote: >> >>> On 12/28/2010 5:39 AM, Thomas Heller wrote: I just saw that you added functional::at. I was wondering about the rationale of your decision to make it a non template. My gut feeling would have been to have proto::functional::at(seq) and not proto::functional::at(seq, N). >>> >>> Think of the case of Phoenix placeholders, where in the index is a >>> parameter: >>> >>> when< terminal >, _at(_state, _value) > >> >> vs: >> >> when >, _at<_value>(_state)> > > Have you tried that? Callable transforms don't work that way. It would > have to be: > > lazy(_state)> > > Blech. Right ... i keep forgetting about that ... >>> For the times when the index is not a parameter, you can easily do: >>> >>> _at(_state, mpl::int_()) >> >> vs: >> >> _at >(_state) >> >> just wondering ... the second version looks more "natural" and consistent > > Still think so? Nope. Let's have it your way :) One other thing though ... struct at { BOOST_PROTO_CALLABLE() template struct result; template struct result : fusion::result_of::at< typename boost::remove_reference::type , typename boost::remove_const::type>::type > {}; template typename fusion::result_of::at::type operator ()(Seq &seq, N const & BOOST_PROTO_DISABLE_IF_IS_CONST(Seq)) const { return fusion::at(seq); } template typename fusion::result_of::at::type operator ()(Seq const &seq, N const &) const { return fusion::at(seq); } }; VS: struct at { BOOST_PROTO_CALLABLE() template struct result; template struct result : result {}; template struct result : fusion::result_of::at< Seq , typename proto::detail::uncvref::type > {}; template typename fusion::result_of::at::type operator ()(Seq &seq, N const & BOOST_PROTO_DISABLE_IF_IS_CONST(Seq)) const { return fusion::at(seq); } template typename fusion::result_of::at::type operator ()(Seq const &seq, N const &) const { return fusion::at(seq); } }; I think the second version instantiates less templates than the first one. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
On 12/28/2010 11:43 AM, Thomas Heller wrote: > Eric Niebler wrote: > >> On 12/28/2010 5:39 AM, Thomas Heller wrote: >>> I just saw that you added functional::at. >>> I was wondering about the rationale of your decision to make it a non >>> template. >>> My gut feeling would have been to have proto::functional::at(seq) >>> and not proto::functional::at(seq, N). >> >> Think of the case of Phoenix placeholders, where in the index is a >> parameter: >> >> when< terminal >, _at(_state, _value) > > > vs: > > when >, _at<_value>(_state)> Have you tried that? Callable transforms don't work that way. It would have to be: lazy(_state)> Blech. >> For the times when the index is not a parameter, you can easily do: >> >> _at(_state, mpl::int_()) > > vs: > > _at >(_state) > > just wondering ... the second version looks more "natural" and consistent Still think so? -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
Eric Niebler wrote: > On 12/28/2010 5:39 AM, Thomas Heller wrote: >> I just saw that you added functional::at. >> I was wondering about the rationale of your decision to make it a non >> template. >> My gut feeling would have been to have proto::functional::at(seq) >> and not proto::functional::at(seq, N). > > Think of the case of Phoenix placeholders, where in the index is a > parameter: > > when< terminal >, _at(_state, _value) > vs: when >, _at<_value>(_state)> > For the times when the index is not a parameter, you can easily do: > > _at(_state, mpl::int_()) vs: _at >(_state) just wondering ... the second version looks more "natural" and consistent ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
On 12/28/2010 5:39 AM, Thomas Heller wrote: > I just saw that you added functional::at. > I was wondering about the rationale of your decision to make it a non > template. > My gut feeling would have been to have proto::functional::at(seq) > and not proto::functional::at(seq, N). Think of the case of Phoenix placeholders, where in the index is a parameter: when< terminal >, _at(_state, _value) > For the times when the index is not a parameter, you can easily do: _at(_state, mpl::int_()) -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
Eric Niebler wrote: > Proto ships with a very small collection of callables for use in Proto > transforms: wrappers for fusion algorithms like reverse and pop_front > and the like. For 1.46, there will be a few more: make_pair, first, > second, and wrappers for a few more Fusion algorithms. It's woefully > incomplete, though. > > I have an idea. Phoenix3 defines *all* these juicy callables under the > stl/ directory. I can't #include them in Proto because that would create > a circular dependency. Why don't we just move the definitions of the > function objects into Proto and make them Proto callables? Phoenix3 can > just #include 'em and use 'em. > > Thoughts? I just saw that you added functional::at. I was wondering about the rationale of your decision to make it a non template. My gut feeling would have been to have proto::functional::at(seq) and not proto::functional::at(seq, N). ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
On 12/19/2010 12:21 AM, Thomas Heller wrote: Eric Niebler wrote: Proto ships with a very small collection of callables for use in Proto transforms: wrappers for fusion algorithms like reverse and pop_front and the like. For 1.46, there will be a few more: make_pair, first, second, and wrappers for a few more Fusion algorithms. It's woefully incomplete, though. I have an idea. Phoenix3 defines *all* these juicy callables under the stl/ directory. I can't #include them in Proto because that would create a circular dependency. Why don't we just move the definitions of the function objects into Proto and make them Proto callables? Phoenix3 can just #include 'em and use 'em. Thoughts? Wonderful idea! I like it. Good idea. Let's do it. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] expanding Proto's library of callables
Eric Niebler wrote: > Proto ships with a very small collection of callables for use in Proto > transforms: wrappers for fusion algorithms like reverse and pop_front > and the like. For 1.46, there will be a few more: make_pair, first, > second, and wrappers for a few more Fusion algorithms. It's woefully > incomplete, though. > > I have an idea. Phoenix3 defines *all* these juicy callables under the > stl/ directory. I can't #include them in Proto because that would create > a circular dependency. Why don't we just move the definitions of the > function objects into Proto and make them Proto callables? Phoenix3 can > just #include 'em and use 'em. > > > > Thoughts? Wonderful idea! I like it. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
[proto] expanding Proto's library of callables
Proto ships with a very small collection of callables for use in Proto transforms: wrappers for fusion algorithms like reverse and pop_front and the like. For 1.46, there will be a few more: make_pair, first, second, and wrappers for a few more Fusion algorithms. It's woefully incomplete, though. I have an idea. Phoenix3 defines *all* these juicy callables under the stl/ directory. I can't #include them in Proto because that would create a circular dependency. Why don't we just move the definitions of the function objects into Proto and make them Proto callables? Phoenix3 can just #include 'em and use 'em. Thoughts? -- Eric Niebler BoostPro Computing http://www.boostpro.com ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto