On 28/06/2012 21:09, Eric Niebler wrote:
After meditating on this for a bit, a thought occurred to me. Your
unpack function is a generalization of the pattern used by the _default
transform.
It is indeed.
Generators are intended to meet this need. What are they lacking for
you? Is it the lack of an "unpack" transform?
We use generators for something else. Generators are in charge of
putting a raw expression in the NT2 domain, which involves computing the
logical size of the expression as well as the type it would have it
evaluated.
Doing the expression rewriting in the generator itself causes dependency
problems, since expression rewriting is defined in terms of unpacking
then re-making expressions, which involves calling the generator.
I don't know yet how we could do what we need in a generator-less world.
Both optimize and schedule require containing children by value to
function correctly.
How is this relevant?
When using normal Proto features, the expressions built from operators
contain their children by reference while the expression built from
transforms contain their children by value.
Since in our case we use the same code for both, we had to always
contain children by value.
Transforms are not pure functional. The data parameter can be mutated
during evaluation.
The transform language is functional since the only thing it does is
define a calling expression which is a combination of primitive
transforms. Of course each primitive transform doesn't have to be
functional, but the language to use them cannot define state, it can
just pass it along like a monad.
I guess it's not pure functional though because of proto::and_.
In any case, a lot of non-trivial expression evaluation strategies
cannot be practically implemented as a transform and require a primitive
transform.
If everything ends up being primitive transforms, we might as well use
simple function objects directly, which are not tied by constraints such
as arity, state, data, environment etc., just store whatever state is
needed in the function object or bind that state with boost::bind or
similar.
I'd like to see Proto provide algorithms like this that accept arbitrary
function objects and that are not intended to require transforms to do
useful things.
You know about proto::vararg, right? It lets you handle nodes of
arbitrary arity.
The transformations that can currently be done as a non-primitive
transform when the transformation must not rely on an explicit arity of
the expression are extremely limited.
Adding unpacking transforms would certainly make it more powerful, but
still not as powerful as what you could do with a simple function object
coupled with macros or variadic templates.
I think it's important to keep in mind that transforms are a possible
solution that can work well for some languages, but that there should be
other solutions as well.
Once there is an unpack transform, will you still feel this way?
We already have the unpack algorithm that I described. It's relatively
simple and straightforward code. We used to have it defined as a
primitive transform, it was much more complicated to use and required
adding special cases for state and data, and was limited to just that.
I don't see how using a transform that does the same thing but less
generic would be useful to us.
_______________________________________________
proto mailing list
proto@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/proto
