On Sat, Sep 27, 2008 at 6:16 AM, Joel de Guzman <joel@boost-consulting.com> 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