Proto for Boost mailing list page: Re: [proto] _unpack transform

Subject: Re: [proto] _unpack transform
From: Eric Niebler (eric_at_[hidden])
Date: 2012-07-11 12:55:11

On 7/11/2012 12:42 AM, Thomas Heller wrote:
> On 07/10/2012 11:18 PM, Eric Niebler wrote:
>> I just committed to the proto-11 codebase a new transform called
>> _unpack. You use it like this:
>>
>>    _unpack<f0(Tfx, f1(_)...)>
>>
>> Where Tfx represents any transform (primitive or otherwise) f0 is any
>> callable or object type, and f1(_) is an object or callable transform.
>> The "..." denotes pseudo-pack expansion (although it's really an C-style
>> vararg ellipsis). The semantics are to replace "f1(_)..." with
>> "f1(_child<0>), f1(_child<1>), etc.".
>>
>> With this, the _default transform is trivially implemented like this:
>>
>> struct _default
>>    : proto::or_<
>>          proto::when<proto::terminal<_>, proto::_value>
>>        , proto::otherwise<
>>              proto::_unpack<eval(proto::tag_of<_>(), _default(_)...)>
>>          >
>>      >
>> {};
>>
>> ...where eval is:
>>
>> struct eval
>> {
>>      template<typename E0, typename E1>
>>      auto operator()(proto::tag::plus, E0&&  e0, E1&&  e1) const
>>      BOOST_PROTO_AUTO_RETURN(
>>          static_cast<E0&&>(e0) + static_cast<E1&&>(e1)
>>      )
>>
>>      template<typename E0, typename E1>
>>      auto operator()(proto::tag::multiplies, E0&&  e0, E1&&  e1) const
>>      BOOST_PROTO_AUTO_RETURN(
>>          static_cast<E0&&>(e0) * static_cast<E1&&>(e1)
>>      )
>>
>>      // Other overloads...
>> };
>>
>> The _unpack transform is pretty general, allowing a lot of variation
>> within the pack expansion pattern. There can be any number of Tfx
>> transforms, and the wildcard can be arbitrarily nested. So these are
>> all ok:
>>
>>    // just call f0 with all the children
>>    _unpack<f0(_...)>
>>
>>    // some more transforms first
>>    _unpack<f0(Tfx0, Tfx1, Tfx2, f1(_)...)>
>>
>>    // and nest the wildcard deeply, too
>>    _unpack<f0(Tfx0, Tfx1, Tfx2, f1(f2(f3(_)))...)>
>>
>> I'm still playing around with it, but it seems quite powerful. Thoughts?
>> Would there be interest in having this for Proto-current? Should I
>> rename it to _expand, since I'm modelling C++11 pack expansion?
>>
> i think _expand would be the proper name. Funny enough i proposed it
> some time ago for proto-current, even had an implementation for it, and
> the NT2 guys are using that exact implementation ;)
> Maybe with some extensions.
> So yes, Proto-current would benefit from such a transform.

You're referring to this:

http://lists.boost.org/proto/2010/11/0304.php

I should have followed through! The code referenced there isn't
available anymore. I remember putting it on my TODO list to understand
the compile-time implications of it, because of your warning about
compile times. And then ... I don't remember. :-P

I remember that it was an invasive change to how Proto evaluates all
transforms, which made me nervous. I also don't think that exact syntax
can be implemented without forcing everybody to pay the compile-time
hit, whether they use the feature or not. In contrast, having a separate
_unpack transform isolates the complexity there.

I'm going to keep playing with this. Your suggested syntax is nice. I
wonder how close I can get. (Although I kinda like my pseudo-pack
expansions, too. :-)

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