Re: [boost] Review: lambda library

From: Chuck Allison (cda_at_[hidden])
Date: 2002-03-22 14:17:04

>From the point of view of a member of J16, I must say that Bill's comments
make a lot of sense to me. We need the flexibility he speaks of to stretch
and test the libraries before they're ready to be considered for
standardization. I realize there are other valid points of view (especially
for users of Boost in production code), but if I understand correctly, what
Bill describes is the very reason Boost exists. I think Boost is the single
best collective effort to help form the next version of standard C++.

----- Original Message -----
From: "William Kempf" <williamkempf_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, March 22, 2002 11:45 AM
Subject: RE: [boost] Review: lambda library

> >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
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>