"Brian McNamara" <lorgon@cc.gatech.edu> escribió en el mensaje news:20040218002607.GD20830@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