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

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

On 12/7/2010 3:13 PM, Thomas Heller wrote:
> Eric Niebler wrote:
>> 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 ...

So transform_impl strips the data parameter of the let scope stuff, and
the local variables like _a don't use transform_impl and see the scope
with the locals?

Well, it's not that simple.... Consider:

  make< int(_a) >

If make::impl uses transform_impl, it strips the let scope before _a
gets to see the local variables. If this is to work, most of Proto's
transforms must be "special" and pass the let scope through. That means
proto::call, proto::make, proto::lazy and proto::when, at least. But ...
it just might work. Good thinking!

<time passes...>

No, wait a minute. Look again:

struct T : transform<T> {

  template<class E, class S, class D>
  struct impl : transform_impl<E, S, D> {

    // do something with D

  };

};

T::impl gets passed D *before* transform_impl has a change to fix it up.
Any existing transform that actually uses D and assumes it's what they
passed in is going to be totally hosed. In order to make existing
transforms let-friendly, they would all need to be changed. That's no good.

Bummer, I was excited for a minute there. :-/

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com