Proto for Boost mailing list page: Re: [proto] proto-11 progress report

Subject: Re: [proto] proto-11 progress report
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2012-06-29 07:49:18

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.