Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2004-02-19 16:38:12


"Brian McNamara" <lorgon_at_[hidden]> escribió en el mensaje
news:20040219190338.GH29345_at_lennon.cc.gatech.edu...
> 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?
>
Oh, I intended to be clear on this :-)
I propose to change the syntax of "let" to leave operators free for lambda
expressions
(I like what it does rather than how I write it)

Fernando Cacciola
SciSoft


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