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 _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto