[boost] Re: lambda

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-02-19 11:14:57

"Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje
news:20040218002607.GD20830_at_lennon.cc.gatech.edu...
> Lambda
>
> There's been a bit of discussion about FC++ lambda on the Boost list, so
> I think it is pretty well-understood at this point.  The documentation
> (and some prior discussions) explain the differences from boost::lambda.
>
> There are occasionally cases where I think FC++ lambda expressions are
> better[*] than boost::lambda expressions, but in most cases,
> boost::lambda provides the most concise solution.
>
> [*] where "better" means shorter, easier to read/write, or other
>     intuitive measures of "goodness"
>
> Monads depend on lambda; in my opinion, over the long term, I think
> monads will be the main "selling point" that makes it worth keeping
> fcpp::lambda around in addition to boost::lambda.
>

Here's my review of the lambda sublibrary:

FCPP Lamba is "explicit" as opposed to "implicit" as in BLL.
That is, I don't create a lambda expression on the fly by merely putting a
placeholder somewhere in the expression; rather, I have to use brackets (%
for infix notation).

I really like this part of the design....
I was myself caught at the "early evaluation" problems of implicit lambda
until trained to put BLL's "protect()" on the right place.

When you work with complex lambdas it's hard to get it right (that is, avoid
all possible early evaluations) implicitly, yet explicitly (the way FC++
works), it's straight forward (even if it requires a more adorned syntax).

OTOH, I don't agree with the arguments against overloaded operators.
Since FC++ lambda expressions are explicit I can't see any overload
resolution problems.
Given that C++ allows you to overload operators is hard to understand why
would I have to write
[X %plus% 1] instead of [X+1]

The docs says that this is in order to keep the interface small, that a
compact interface is easier to remember that a wide one.
However, C++ operators are so ubiquitous that the above argument doesn't
hold... no one needs to "additionally" remember that he can use
operators.... rather, with FC++, we need to remember that when can't; and
furthermore, we need to remember what the spelling for "==" is: %equal%,
%equal_to%, or whatever.

Also, lambda comprenhesions and guards do use overloaded operators. IMO,
this library feature will be much less frequently used than lambda
expressions per see, so IMO those overloads should be moved into the
expressions themselves and taken out from the comprenhensions/guards.

This of course doesn't mean that the %f% should be drop alltoghther, or that
the operator-like functoids removed.
Just allow lambda expression to use (the most common at least) C++
operators.

Anyway, I think comprenhensions, guards, "let"/"letrec" and the LEType
subsystem are great library features, so I'd like to keep this part of the
library even thought it overlaps partially BLL.

(more to come)

Fernando Cacciola
SciSoft