Peter Dimov wrote:
Joel de Guzman: ...
This:
lambda( _x, _y, _z = 123 )[ ... ]
will be transformed to this:
lambda( _x = _1, _y = _2, _z = 123 )[ ... ]
I wonder though if it's a good idea to separate the signature from the locals:
lambda( _x, _y )[ let( _z = 123 )[ ... ] ]
seems to be more "idiomatic"? No?
Under my mental model of the "new lambda", these two are not the same. _z = 123 in the lambda initializes _z to 123 once when the lambda is defined; let _z = 123 declares _z to be 123 each time the lambda is called. That is, the outer _z is a member variable, the inner _z is a local temporary.
So, if we return to my generator example that was to yield 1, 2, 3 on successive calls, it would be spelled
lambda( _a = 0 )[ ++_a ]
as I first expected.
Hrm. I'm not so sure about this one. I think I prefer Steven's suggestion to follow C++ lambda in that _a = 0 mimicking default arguments.
Incidentally, you might consider supporting a scopeless let (if it doesn't already work):
lambda(_x, _y)[ let( _z = _x + _y ), _z * _z ]
Nice one!
analogous to a C++ local variable:
auto _z = _x + _y; return _z * _z;
and maybe even dispense with the let at all:
lambda(_x, _y)[ _z = _x + _y, _z * _z ]
Hmm. Might be tough.
although this has the usual drawback with being ambiguous with an assignment to an outer-scope _z:
lambda( _x, _y, _z = 0 )[ _z = _x + _y, _z * _z ]
Ok, all good points. Let me start and I'll see what can be done. I think all the ingredients are already present. It's just a matter of having the right behavior. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net