Proto for Boost mailing list page: Re: [proto] : Proto transform with state

Subject: Re: [proto] : Proto transform with state
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2010-12-07 15:13:26

Eric Niebler wrote:

> On 12/7/2010 2:58 PM, Thomas Heller wrote:
>> Eric Niebler wrote:
>> 
>>> On 12/7/2010 12:57 PM, Thomas Heller wrote:
>>>>
>>>> *Dough* misunderstanding here. I didn't mean to clean up the phoenix
>>>> scope expressions with the help of proto::let. I was thinking, maybe
>>>> proto::let can borrow something from phoenix scopes on a conceptual
>>>> level.
>>>
>>> Oh, sure. How does Phoenix handle let scopes? Are local variables
>>> statically or dynamically scoped? How is it accomplished?
>> 
>> Phoenix in general has an abstract concept of an environment. This
>> environment is used to store the arguments of a lambda expression in a
>> tuple. This leads to the only requirement this environment must have:
>> access the arguments with a compile-time index in that tuple, using
>> fusion::at_c<Index>(env).
>> When having a let statement, A new environment is created which acts as a
>> map like data structure, indexed by the local names. Additionally the
>> above requirements are fulfilled.
>> Local variables are dynamically scoped. Additionally you can access
>> locals defined in some outer let scope.
>> 
>> This is basically how it is working. I was thinking, maybe, proto can
>> adapt this concept of an environment. This would allow pretty nifty
>> things, like not being tied to only state and data, which really can be a
>> limitation, sometimes. Backwards compatibility can be provided by
>> transparently change proto::_state and proto::_data to do the right
>> thing.
> 
> That is not sufficient to preserve back-compat. Imagine someone has
> defined a PrimitiveTransform T:
> 
> struct T : transform<T> {
> 
>   template<class E, class S, class D>
>   struct impl : transform_impl<E, S, D> {
> 
>     // do something with D
> 
>   };
> 
> };
> 
> Now they do: T()(e,s,d). Inside T::impl, D had better be the type of d.
> Nowhere does the _data transform appear in this code, so changing _data
> to be "smart" about environments and scopes won't save you if you've
> monkeyed with the data parameter.

Very true. Something like proto::transform_env_impl could help. Introduce a 
new type of primitive transform which is aware of this environment. The 
usual transform_impl can still be used.
By calling T()(e,s,d) you just create a 2-tuple. The first parameter is the 
state, second data.
Just thinking out loud here ...