Boost logo

Boost :

Subject: Re: [boost] [Phoenix] review
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-10-02 12:17:41

Joel de Guzman wrote:
> David Abrahams wrote:
>> on Wed Oct 01 2008, Joel de Guzman <> 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

     "what:" >> eps[foo()]

I don't want foo() to be immediate!

Oh my... this behavior, while cool, might not be practical after all.


Joel de Guzman

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