Boost logo

Proto :

Subject: Re: [proto] : Proto transform with state
From: Eric Niebler (eric_at_[hidden])
Date: 2010-12-07 14:03:18

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.

Eric Niebler
BoostPro Computing

Proto list run by eric at