Joel de Guzman wrote:
Steven Watanabe wrote:
AMDG
Giovanni Piero Deretta wrote:
I'm not an expert on modern FP, but the above lambda doesn't seem like a classic lambda (as in lambda calculus and Lisp) to me.
Now that I've seen what Phoenix can do, I think that, were I to design a Boost.Lambda2, I'd probably go with a classic lambda of the form
lambda( _x, _y )[ _x + _y ]
where the inner _x + _y is not a function object, and it is the lambda[] that turns it into one. (That is, the evaluation of an inner expression would be done with eval(expr, args...) and not with expr(args...).)
Oh yes please! Unfortunately I think that this would require major surgery of phoenix...
+1 from me for that syntax.
I don't think that it will actually require major surgery after all. It really just requires a small adjustment of the environment.
Hmmm... I don't think Phoenix requires a major surgery for this.
Ok, Easy. It's just a matter of filtering the /bare/ variables in the lambda declaration (using fusion! hurray) and transforming the list of declarations (again fusion!) such that each unassigned variable takes an argument. 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? In the last case, lambda just takes in the signature. Let "let" do the locals. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net