On Thu, Feb 19, 2004 at 01:14:57PM -0300, Fernando Cacciola wrote:
Here's my review of the lambda sublibrary:
Thanks for these comments! One comment/question in return: ...
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.
I am just trying to clarify your opinion. You like "let"; in FC++, "let" works something like this: // inside a lambda expression let[ X == 3 ].in[ someLambdaExpressionInvolvingX ] You also say you would like it if common operators were overloaded, so we don't have to write X %equal% 3 I think as it stands now, these two are incompatible goals. We are currently overloading == to mean let-binding; we could overload it to mean %equal%, but then I'd want new syntax for let-binding. (Similarly, F[X] means delayed function call, not array indexing, as things currently stand.) How you would choose to resolve this issue? -- -Brian McNamara (lorgon@cc.gatech.edu)