On Thu, Aug 25, 2011 at 12:04 AM, Mathias Gaunard <mathias.gaunard@ens-lyon.org> 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.