Re: [boost] [Phoenix] Some questions and notes...

Subject: Re: [boost] [Phoenix] Some questions and notes...
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2008-09-30 12:52:43

On Sat, Sep 27, 2008 at 6:16 AM, Joel de Guzman
<joel_at_[hidden]> wrote:
> Giovanni Piero Deretta wrote:
>
>>> Are you suggesting that you want phoenix functions to be "optionaly
>>> lazy" too? Currently, they are not. That can be done, but I need
>>> more convincing.
>>>
>>
>> I would love if they were. But I can live with a layer on top of that.
>> About the convincing part... hum I guess the only way is to try them
>> and see if one find them convenient. For me it started as an
>> experiment that worked.
>
> Don't stop! Don't backout now that I'm starting to get convinced ;)
> I know the value of your suggestion. I've actually pondered on this
> a long time ago.
>

I really would like to bring other arguments, but it really seems
something one has to get used to.

>>>>>> Anyways, I can live with the current design, 'optional lazyness' could
>>>>>> be built on top of phoenix lazy functions. My only compliant is that
>>>>>> the 'lambda[]' syntax is already taken.
>
> If we are to break the interface, I want to do it right.
> Your feedback here is invaluable. The lambda[] behavior is
> not set in stone, so to speak. I just want to be sure I'm
> making the right decisions when changing the interface.
> I cannot affort a failed experiment.
>

IMHO always requiring lambda[] (and changing a bit the current
lambda[] behavior) is more future proof than the other solution. The
'lambda' keyword provides a simple place to hook extra solutions.

>>> In general though, I tend to avoid special cases. This
>>> "optional laziness" is based on special casing depending
>>> on some qualities of a lambda function.
>>
>> Well, I guess that is a point of view.. as I see it, functions are
>> usually evaluated, unless some of the arguments are suspended: it is
>> not eager evaluation that is special, but lazyness (or partial
>> application or whatever you want to call it).
>
> And it is a valid point of view. Recall in the brief introduction
> that "The focus is more on usefulness and practicality than purity,
> elegance and strict adherence to FP principles.". I do admire
> people like you who embrace FP and pure functions. I try to
> do as much FP as I can. But in the real world, it's C++ we
> are dealing with with the side-effects, with the imperative
> code, etc.

I'm an engineer so for me practicality is everything :)

I try to practice a functional approach to programming simply because
ditching as much mutable state as possible let me reason about a
system more easily. The catch  is, as usual, in the 'as much as
possible'.

>
> This is not the first time things like this are brought into light
> though. As I said, I already pondered on this a long time ago.
> I'm definitely interested with your approach. And, as someone
> who already made progress in that route, I would love to collaborate
> with you on having a facility like this built on top of phoenix.
>

Ok, I do not think it will be hard! I'll start to look to the current
phoenix V3.

>
>>   int i = 0;
>>
>>   lambda[ i+= arg1]; //default capture by value
>>   lambda_r[ i += arg1]; //default capture by reference
>>
>> It would make Phoenix similar to C++0x lambdas.
>> Without requiring lambda[]  [1] I do not see how this could be
>> implemented (expecially if you want the default capture behavior to be
>> by value).
>
> I'm not sure about this one. What makes this better than
> just having ref(i) ?
>

With just a single captured variable, it is more or less the same, but
with complex lambda expressions were you need to capture many
variables by reference (because you need to mutate or simply they are
expensive to copy), it makes a difference. C++0x lambdas do the same.

In general, I find that the most of my lambdas have a shorter lifetime
than the variables they capture, so capture by (const) reference as
default would work for me. OTOH having an simple syntax to switch from
one mode to the other without requiring to explicitly mark every
variable is a good thing.

-- 
gpd