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

Subject: Re: [boost] [Phoenix] Some questions and notes...
From: Joel de Guzman (joel_at_[hidden])
Date: 2008-09-27 00:16:49

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 usually assume that an expression is not lazy unless I see a
 >>> placeholder in the right position. I do not think that generic code
 >>> makes thing worse: I carefully wrap all function parameters with the
 >>> equivalent unlambda [1] *before* I pass them to higher order
 >>> functions. In fact I always have to because in general I do not know
 >>> if a certain function is optionally lazy or not.
 >> This is exactly the problem I see with generic code.
 >>
 >
 > In general the compiler will loudly tell you if you get something
 > wrong (even if the errors might be unintelligible). Except of course
 > for something like the example below...

Imperative code. Right.

[snip more on "optional-laziness"]

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

 >> Those are pretty cool code. I'm still not sure of the implications
 >> of all these though. I know for sure that people less smarter than
 >> you are tend to get bitten by expressions that are intended to
 >> be lazy but are actually immediate. Perhaps we can be arrange
 >> for an "optionaly-lazy" layer on top of phoenix: it can be done,
 >> phoenix is modular enough to have that layer.
 >>
 >
 > It would be great.
 >
 >> 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.

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.

 > specific variable must be captured by reference? Lambda has it, but is
 > a bit cumbersome:
 >
 >   int i =0;
 >   var_type<int> r_i = var(i);
 >   (_1 + r_i)(0);  //capture by ref
 >
 > something like this is desirable (and in fact can be done easily, but
 > IMHO should be part of the library):
 >
 >   byref<int> i = 0;
 >   (_1 + i)(0); // capture by ref

Phoenix has it but is not as terse. I think your suggestion
is good.

 > BTW, yet another reason for always requiring lambda[] or something
 > equivalent: the library could delay the decision of capturing by
 > reference or by value by default up to the lambda introducer (I think
 > I already mentioned something like this in the past):

Yes.

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

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