Re: [boost] [Phoenix] review

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 <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