Re: [proto] _unpack transform (was: proto-11 progress report)

[Bart Janssens]

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

[proto] _unpack transform (was: proto-11 progress report)

[Eric Niebler]

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?

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

___
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto