Re: [boost] painless currying

Subject: Re: [boost] painless currying
From: Thomas Heller (thom.heller_at_[hidden])
Date: 2011-08-25 02:48:21

On Thu, Aug 25, 2011 at 12:04 AM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> On 08/24/2011 07:09 PM, Thomas Heller wrote:
>
>> Of course, in order to transform such a call node though, you need to
>> implement the specific behaviour in the operator() Â overloads of
>> phoenix::actor.
>> I can see this happening though ... could be almost trivial ... we
>> could add a post processing actions step to the evaluation which
>> returns false_ if the expression shouldnt be evaluated just yet, or
>> true_ otherwise. A function_eval  node (which is, in a way equivalent
>> to your imaginary call node) can then select the proper action based
>> on which types it holds. For that we can reuse the logic Eric
>> proposed.
>
> Ok, it seems phoenix::function doesn't work like I thought.
> Why doesn't it just do a proto::make_expr(proto::tag::function, f, a0,
> a1..., aN)?
> I don't really understand how Phoenix works.
>
> For some reason I thought the node type for function application in Proto
> was called 'call', looks like it's actually 'function', sorry.

As i said, it is function_eval. To be more precise
boost::phoenix::detail::function_eval.
It is used by phoenix::function and phoenix::bind. Don't remember why
i didn't just reuse proto::tag::function here ... One reason was that
would have to rewrite the function evaulation once again to support
phx2 style result type deduction ....

Anyway. Hooking up this function_eval thing with curry capabilities
will automatically give you "lazy" through bind and curry.