RE: [boost] Review: lambda library

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-03-22 13:45:00

>From: "Asger Alstrup Nielsen" <alstrup_at_[hidden]>
>Reply-To: boost_at_[hidden]
>To: <boost_at_[hidden]>
>Subject: RE: [boost] Review: lambda library
>Date: Fri, 22 Mar 2002 19:24:23 +0100
>
>Just a few comments to your kind reply.
>
> > So why should everyone else wait 1.5 years for another
> > "better" library to come out? A new one won't break
> > existing code using LL. We are not proposing
> > to change the C++ Standard, only offering a very useful
> > library that has had a lot of work put into it. That is
> > reasonably well tested and to us seemsvery useful as is.
>
>People can download the library and use it if they want to, because you
>make it publically available, today. The interested users do not have to
>wait. They can use it today if they want to, thanks to your generous
>licensing.
>
>Of course, Boost increases the user base significantly because once it
>is in there, it has got a stamp of approval and a distribution process
>going. Also, the review process itself improves the library.
>But the other side of the coin is that once it is in Boost, it will
>become harder to change it, because you have the responsibility of
>maintaining some kind of backward compatibility.

This simply is FUD.  No matter what distribution mechanims is used you have 
at least some responsibility to strive for backwards compatibility.  Some 
distributions even, by convention, *require* this.  Boost, however, does 
not, nor should it.  There are things coming down the pipe for Boost.Threads 
that may well break backwards compatibility (hopefully it won't, but it may) 
and it wouldn't be unfortunate, given the goals of Boost, if this were not 
allowed.

> > I agree here. Yet to deny users a chance to use the best
> > current existing practice merely because something better
> > is coming is IMO, a poor choice for rejecting this library.
>
>Rejection is not the same as denying users the chance to use the
>library.

True, but it does send a very heavy message to many users.  I don't see a 
need to send such a message in this case.  The whole field of FP and C++ may 
be too new for us to judge whether or not LL will withstand the tests of 
time or not, but we need to give it the benefit of the doubt to move 
forward.  I see the things brought up by Pheonix, et. al. as valid design 
ideas that may be applied to LL in the future, but not as killer arguments 
to reject it's inclusion today.

>[LL is accepted now, and over time, the scope is increased]
> > I'd go with #2. The same way we are doing with "Threads." It
> > works, let people use it. Add functional programming to it if
> > you want it, see how that works. If you _REALLY_ like it and
> > use it, add it, propose a new one etc.
> >
> > Lambda may be fairly mature, but it is not static. We can
> > always push out a version 2.
>
>The whole question is a question of the timeframe. When do we
>realistically think that a better alternative will be available?
>
>If it turns out, as Peter Dimov suggested, that it is easy to add for
>instance scoping to LL, and correspondingly adopt some of the other
>ideas from the competitors, I think it is an honourable to say: Ok,
>something new has come up, and we will take a time out for a few months
>until we assimilate the new technology, because this could have a very
>significant impact.
>
>And looking from the outside, the other alternative scenario is that
>Joel is moving so fast on his own that he will be ready with Phoenix
>within a few months.

Niether of these mandate a rejection of LL today.

>If any of these scenarios are realistic, then it seems to be that it
>could pay off to hold the horse for this timeframe.

I think you come to this conclusion only because you believe libraries 
accepted into Boost should be set in stone, and I don't agree with this.

>Now, you respond: It will happen faster if you help. This is only fair.
>But I'm afraid that I do not have the skills and the time to really help
>out. As a poor excuse, I'm also tied to VC6, and thus I'll have a hard
>time to contribute.
>
>[Weak arity]
> > This is under discussion between others on this thread, and
> > so far I haven't seen a convincing argument.
>
>The main argument I have is that it is not symmetric:
>
>(_2)(2, 3) is OK, but (_1)(2, 3) is not.
>
>This seems a bit arbitrary to me.

I haven't seen a compelling argument for either side of this one, actually, 
but I lean towards weak arity myself.  It's simply more flexible, and that's 
what this stuff is all about!

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com