Boost logo

Boost :

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
> version of LL. Although since then I've learned a number of useful
> techniques for getting around the lack of template specialization.
> said, MS did the right thing and is about to release an update which
> 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

> 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.
> there was a complaint about LL being over engineered, in this case it
> 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
> more I suspect we'll see a settling down of requirements. So far the
> boils down to callbacks and whether LL bind fits all the requirements.
> there is already an boost::bind, it's not going to hurt that the
> 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
> 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
> anonymous C++ in C++. Hence your complaint about complexity is really
> complaint that C++ is complex. One follows the other. Our choice was
> segregate things into separate include files so that those wishing to
> 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.
> 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
> with expression templates. But why wait to use a tested functional
> 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

> So Dave, I value your opinion, I do hope you can make a bit more time
> look at this library closely, and not just waffle about, its worth it.
> 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at