Boost logo

Boost :

From: Brian McNamara (lorgon_at_[hidden])
Date: 2003-10-08 22:39:20


On Wed, Oct 08, 2003 at 10:24:05PM -0400, David Abrahams wrote:
> After some more thought, I have a question: what's the meaning of:
>
> // f(x) -> 2*(x+3)
> lambda(X)[
> let[
> Y == X %plus% 3 // y = x+3
> , Fun == multiplies(2) // fun(x) -> 2*x NOTE PARENS
> ].in[
> Fun[Y] // fun(y)
> ]
> ]
>
> ??
>
> if it's the same as
>
> // f(x) -> 2*(x+3)
> lambda(X)[
> let[
> Y == X %plus% 3 // y = x+3
> , Fun == multiplies[2] // fun(x) -> 2*x NOTE BRACKETS
> ].in[
> Fun[Y] // fun(y)
> ]
> ]

It is the same. More generally, inside a lambda expression,

   f(cppexpr) = f[cppexpr]

holds true for all "f" which do not cause side-effects. (Subject to
the constraint that "cppexpr" is a C++ expression, and not a lambda
expression. When "cppexpr" is a lambda expression--let's now call it
"lexpr" instead--"f(lexpr)" usually doesn't compile, and when it does,
it typically means something different than "f[lexpr]".)

> Then I'm inclined to think
> parens-on-lambda-variables-delays-evaluation is a reasonable idea.

Again, another reason I am un-fond of this is because I perceive it to
be accident prone. The lambda library example from the DPCOOL paper is
a good one. (These examples actually don't work, but for merely
distracting reasons which I'll describe later[*].)

   // boost::lambda
   // print each element
   for_each( begin, end, cout << _1 << endl );
   
   // Now let's add leading text to each line
   for_each( begin, end, cout << "X is " << _1 << endl ); // whoops!

Using FC++ lambda, the example would go

   // print each element
   for_each( begin, end,
      lambda(X)[ &cout %out_stream% X %out_stream% endl ] );

   // Now let's add leading text to each line
   for_each( begin, end,
      lambda(X)[ &cout %out_stream% "X is " %out_stream%
                       X %out_stream% endl ] ); // works

which avoids the accident in the first place. (This example also
illustrates that FC++ is not the best tool for every job (way to
verbose!), but I want to concentrate on the "accidental early
evaluation problem" right now.)

Now, if we overload () to mean [] for lambda expressions, then the FC++
examples become:

   // print each element
   for_each( begin, end,
      lambda(X)[ &cout ^out_stream^ X ^out_stream^ endl ] );

   // Now let's add leading text to each line
   for_each( begin, end,
      lambda(X)[ &cout ^out_stream^ "X is " ^out_stream^
                       X ^out_stream^ endl ] ); // whoops!

and we are right back to the same accident as in boost::lambda.

I don't like that. I prefer the explicit control of using [] and % to
delay evaluation, rather than the implicit control of whether-or-not-
there-happens-to-be-a-lambda-variable-in-this-expression-subtree.
Seemingly-innocuous changes to an expression ought not change its
overall semantics. This is my opinion.

[*] As promised, here are the notes about why none of these examples
compile.

First, both the lambda and FC++ examples try to use "endl". But the way
C++ defines "endl" makes it far-too-slippery a beast to be captured by
such simplicity. See my previous messages in different threads (my
messages talk about "make_manip") for details.

Second, I doubt the FC++ example can handle the string literal. I had
forgotten about this issue, and I should issue a general call for
help. When you try to capture a string literal in a function like

   template <class T>
   S func( const T& x );

calls to func("literal") deduce T to be an array-of-char type. Since
arrays are not copy-by-value-able in C++, and FC++ does everything "by
value", many FC++ calls involving string literals (usually those
involving currying or lambda) fail to compile. You will notice in FC++
documentation examples that rather than say

   f("foo")

we usually say

   std::string s = "foo";
   f(s)

Now you know why. What a dirty secret. Surely there is some easy
remedy for this, but I have never bothered to try to figure out what.
Advice appreciated.

-- 
-Brian McNamara (lorgon_at_[hidden])

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