Boost logo

Boost :

Subject: Re: [boost] phoenix::bind
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-10-02 20:04:41

Joel de Guzman wrote:
> Steven Watanabe wrote:
>> 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.


     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.


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at