Joel de Guzman wrote:
David Abrahams wrote:
on Wed Oct 01 2008, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
I think I am convinced. Even with phx functions, the expressions expressing the arguments are already "optionally lazy" anyway due to C++:
foo(123 + 456) // foo is a phoenix function
The expression (resulting to the argument) is eagerly evaluated. Whereas:
foo(_1 + 456)
it is not (eagerly evaluated).
So it's really a case by case basis depending on what C++ can evaluate eagerly.
So, it follows that:
foo(123 + 456)
can be evaluated eagerly, not only the arguments, but foo itself. While:
foo(_1 + 456)
can remain lazy, as usual.
It may be the right choice anyway, but keep in mind that any such nonuniformity limits genericity. I think we already have that with Boost.Bind ("nested binds are special") but this effect is worth thinking about.
Yeah, I was thinking about that too. That is why I suggested to work on this on a branch for further investigation.
One possibly nasty effect of this is that this makes phoenix unusable as imperative callback function like in this example: enum { begining, continue_ } set_menu_action("play", do_play(begining)); or in Spirit where in some cases, all args are known yet you want to have a semantic action that's not executed immediately: "what:" >> eps[foo()] I don't want foo() to be immediate! Oh my... this behavior, while cool, might not be practical after all. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net