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 ... _______________________________________________ proto mailing list proto@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/proto