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
