Re: [boost] Review: lambda library

From: William Kempf (williamkempf_at_[hidden])
Date: 2002-03-24 11:35:04

>From: "David Abrahams" <david.abrahams_at_[hidden]>
>Reply-To: boost_at_[hidden]
>To: <boost_at_[hidden]>
>Subject: Re: [boost] Review: lambda library
>Date: Sat, 23 Mar 2002 05:51:11 -0500
>
>
>----- Original Message -----
>From: "Gary Powell" <powellg_at_[hidden]>
>
> > ----------------------------------
> > Ok, I think I understand your ambivalence. Let me try to clarify what
>I hear
> > are the objections (in no particular order)
> >
> > o) You'd like MSVC 6.5 compatibility.
>
>
>Yes. The unfortunate truth right now is that without it, LL becomes far
>less relevant to my work. If I was writing application code, it might
>not be that way, but I'm writing libraries and I can't dump MSVC6.5 yet.

Amen!

> > While I won't say its an
> > impossibility, I gave up after spending countless hours with ET and an
>early
> > version of LL. Although since then I've learned a number of useful
> > techniques for getting around the lack of template specialization.
>That
> > said, MS did the right thing and is about to release an update which
>does
> > handle LL just fine.
>
>I doubt they're quite as close to release as you make out. They only
>just released 7.0 and people are not likely to adopt a near-complete
>rewrite like 7.1 on short notice.

I'm not totally sure this is true.  MS used to release a new VC++ every 
quarter (granted, changes to the compiler were usually fairly minimal, but 
they *did* make compiler changes) and I think most of the VC++ users would 
*love* to see MS go back to this sort of release strategy.  Hint, hint, 
Jason ;).

Further, VS.Net is such a new technology that I'm unsure that many "pure 
C++" developers are switching that fast.  It's quite possible that a very 
large portion of VC++ user base could skip 7.0 entirely and move directly to 
7.1 if it were released quickly.

> > I realize that not all users of 6.5 will be able to
> > upgrade, but to me it no longer justifies the amount of work it takes
>to get
> > around those bugs. (BTW the original ET library did work with MS6.2)
>
>I understand your position, but it doesn't change things for me
>personally (I can still vote with my "boost's best interests" hat on, of
>course).

Well, I think even with "boost's best interests" hot on the conclusion is 
that we should at least try and be compatible with VC++ 6, at least in the 
short term.

> > o) The new if(test)[expression].else_[expression]
> >
> >     Yes this is syntaxic sugar but so is _1 + _2. I like Joel's idea,
>wish I
> > had thought of it myself. But its only an interface change to LL.
>While
> > there was a complaint about LL being over engineered, in this case it
>helps
> > out. Making this alternative syntax on is possible. Nothing like a
>Version 2
> > after some testing and review.
>
>It's encouraging that you seem to be looking seriously at this. I think
>I saw a few other related things in Phoenix using square brackets that I
>liked (he added, vaguely...).

I like some of the ideas discussed about Pheonix, but I personally hope that 
these new ideas aren't enough to warrant voting "no" to LL.  None of the new 
ideas seem to be ideas that will "break" LL, nor do they change how 
effective LL can be *as is*.

> > o) bind issues.
> >
> >    This one has been discussed a lot, and not just in the Lambda
>review, but
> > also in the bind review. There are differing opinions and as bind gets
>used
> > more I suspect we'll see a settling down of requirements. So far the
>issue
> > boils down to callbacks and whether LL bind fits all the requirements.
>Since
> > there is already an boost::bind, it's not going to hurt that the
>current
> > Lambda::bind has a more restricted set.
>
>I'm not sure about that. I think duplicated functionality always hurts a
>little. Also, when I run across a tool like bind which solves a smaller
>problem on a wide range of compilers, I tend to trust its design more
>than a similar tools which is just one component of a much larger
>library, the theory being that the author of the smaller library has
>been able to focus attention on that part of the functionality. Of
>course I realize that LL has been around a lot longer, so the argument
>may not apply. Maybe my instinct is mistaken.

Possibly, but on this subject I tend to agree with the feelings of most 
people here.  I prefer the less strict binding functionality.  That said, 
though, one can always relax this with out breaking any existing code, so 
I'm not going to vote "no" on the basis of this one thing.  If the authors 
really want to keep the strict semantics, we can argue with them later and 
if we convince them they can change the implementation with out effecting 
any users.

> > Although these should become the
> > same interface even if they are not the same underlying
>implementation, to
> > avoid user confusion.
>
>Agreed. I think I agree with others that the default arity checking in
>bind is more appropriate than that in LL.
>
> > Jaakko and I are talking about extending the number of
> > placeholders. That appears to be a linear task. It's just really hard
>to
> > want to put the effort in unless people are really really using it, as
> > opposed to it just being "nice."
>
>FWIW, the moment I released Boost.Python with support for 6 arguments I
>acquired users who wanted 10 and more.

Yes.  Hopefully the preprocessor stuff will help to provide solutions here 
with out the need of tediously coding for each "expansion" of the number of 
arguments.

> > o) New stuff
> >   I suspect that the more smart people look at Expression Templates
>the more
> > cool things we'll see with them. We don't claim to have a lock on good
>ideas
> > with expression templates. But why wait to use a tested functional
>library?
> > It's not that lambda can't evolve.
>
>No, I agree. However, one reason for me to wait is that I still need to
>support platforms that LL does not. I may yet vote positively, but I'm
>not voting negatively because I don't want everyone else to have to
>wait.

One benefit of voting "yes" is that it becomes more likely that someone else 
will pick up the effort of porting the library to VC++.  So lack of VC++ 
support can actually work both ways on how one should vote.

Bill Kempf
williamkempf_at_[hidden]

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.