Re: [boost] Review: lambda library

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-03-23 05:51:11

----- 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.

> 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 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).

> 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...).

> 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.

> 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.

> o) Functional Programming
>
>   LL is not FC++. We didn't attempt to recreate Haskel in C++, but
rather,
> anonymous C++ in C++. Hence your complaint about complexity is really
a
> complaint that C++ is complex. One follows the other. Our choice was
to
> segregate things into separate include files so that those wishing to
only
> use the old ET style of basic operators not have to pay for the more
> advanced LL stuff.

That sounds like a good compromise.

>   I suspect that we could create the functionality of FC++ in Lambda.
I
> haven't done it because I don't program that way. I came from a "C"
> background, not a FP one. If I were to tackle this problem I'd put it
in as
> another layer on the core of LL. Just the same way we put all the
other cool
> stuff in. Each layer solving a separate set of the problems.

It would be nice if the core library and all of the add-ons were better
distinguished from one-another in the documentation.

> 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.

> So Dave, I value your opinion, I do hope you can make a bit more time
to
> look at this library closely, and not just waffle about, its worth it.
We
> spent over 3 years to get where we are today.

I spent some time with the docs the other day, and hope to spend more
still in the near future.

-Dave