On 6/25/2012 12:21 PM, Mathias Gaunard wrote:
> There is a function which is very simple and that I found to be very
> useful when dealing with expression trees.
> unpack(e, f0, f1) which calls
> f0(f1(e.child0), f1(e.child1), ..., f1(e.childN))
> I can do recursion or not with the right f1, and I can 'unpack' an
> expression to an n-ary operation f0.
> Here f0 is typically a function that uses its own overloading-based
> dispatching mechanism.
Now with proto-11, it's not too hard to implement Matias' unpack
function in terms of primitives. You can find an example here:
The functions f0 and f1 can be stateful. It uses the new unpacking
patterns, the slot-based transform environment, and a new bind function
I'm considering adding the slots mechanism to proto-current so that this
can be made to work there, also. The problem is that once you use a
slot, the data parameter is no longer just a dumb blob. I can make
proto::_data ignore the slots and just return the dumb blob as before,
and that will satisfy some. But any custom primitive transforms that
folks have written will need to be ready for the fact that they could
get passed something different than what they were expecting. I don't
think it will break code until you decide to use a slot (or use a
transform that uses a slot). Then you'll need to fix up your transforms.
Does anybody object to the above scheme? The advantage is that things
like Mathias' unpack function become possible. Also, I'll finally be
able to implement the let<> transform. I'd probably be able to change
the implementation of the external transforms feature to make use of
slots, too (although that might be a breaking change, in which case I'd
wait until proto-11).
BTW, the "unpacking patterns" feature will be part of 1.51.
proto mailing list