On Thu, Oct 2, 2008 at 6:17 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
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));
An explicit use of bind might to the trick: bind(do_play, beginning)
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!
wouldn't "what:" >> eps[ foo ] work?
Oh my... this behavior, while cool, might not be practical after all.
I guess it depends a lot on what the most common use case is. -- gpd