Re: [proto] _unpack transform
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: _unpackf0(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(_child0), f1(_child1), etc.. With this, the _default transform is trivially implemented like this: struct _default : proto::or_ proto::whenproto::terminal_, proto::_value , proto::otherwise proto::_unpackeval(proto::tag_of_(), _default(_)...) {}; ...where eval is: struct eval { templatetypename E0, typename E1 auto operator()(proto::tag::plus, E0 e0, E1 e1) const BOOST_PROTO_AUTO_RETURN( static_castE0(e0) + static_castE1(e1) ) templatetypename E0, typename E1 auto operator()(proto::tag::multiplies, E0 e0, E1 e1) const BOOST_PROTO_AUTO_RETURN( static_castE0(e0) * static_castE1(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 _unpackf0(_...) // some more transforms first _unpackf0(Tfx0, Tfx1, Tfx2, f1(_)...) // and nest the wildcard deeply, too _unpackf0(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. ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] _unpack transform (was: proto-11 progress report)
On Tue, Jul 10, 2012 at 11:18 PM, Eric Niebler e...@boostpro.com wrote: 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 _unpackf0(_...) Hi Eric, Is it correct that the above example just generates a sequence of calls to f0, one for every child of the expression? If so, we are currently implementing that functionality like this: https://github.com/coolfluid/coolfluid3/blob/master/cf3/solver/actions/Proto/ExpressionGroup.hpp So for us this would avoid the (in this case quite simple) primitive transform. Cheers, -- Bart ___ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto
Re: [proto] _unpack transform
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: _unpackf0(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(_child0), f1(_child1), etc.. With this, the _default transform is trivially implemented like this: struct _default : proto::or_ proto::whenproto::terminal_, proto::_value , proto::otherwise proto::_unpackeval(proto::tag_of_(), _default(_)...) {}; ...where eval is: struct eval { templatetypename E0, typename E1 auto operator()(proto::tag::plus, E0 e0, E1 e1) const BOOST_PROTO_AUTO_RETURN( static_castE0(e0) + static_castE1(e1) ) templatetypename E0, typename E1 auto operator()(proto::tag::multiplies, E0 e0, E1 e1) const BOOST_PROTO_AUTO_RETURN( static_castE0(e0) * static_castE1(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 _unpackf0(_...) // some more transforms first _unpackf0(Tfx0, Tfx1, Tfx2, f1(_)...) // and nest the wildcard deeply, too _unpackf0(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