Re: [boost] [Phoenix] review

Subject: Re: [boost] [Phoenix] review
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-10-02 12:27:23

On Thu, Oct 2, 2008 at 6:17 PM, Joel de Guzman
<joel_at_[hidden]> 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