Boost logo

Boost :

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


Giovanni Piero Deretta wrote:
> 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)

ermmm...

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

Perhaps. How about this:

     "what:" >> eps[ foo(123, "busted") ]

ah, yeah, bind again... Tedious.

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

Probably :-*

Regards,

-- 
Joel de Guzman
http://www.boostpro.com
http://spirit.sf.net

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk