RE: [boost] Review: lambda library

From: Gary Powell (powellg_at_[hidden])
Date: 2002-03-22 14:05:18

> Dave did not vote against the Lambda Library, he abstained. However,
his
> message was confusing to read. Dave, would you like to clarify?

Not sure what to say; I'm ambivalent. I think the LL would be a valuable
addition to boost, but I think others working in the same area have had
insights which I'd like to see incorporated into any boost FP library we
accept. Some of the syntactic innovations in Phoenix resonate for me
immediately in ways that the LL syntax does not. The impact of this is
not to be underestimated (i.e. don't say "it's just syntactic sugar" -
if sugar didn't count we would program in machine code). Some of the
design decisions in the boost bind library (and Phoenix) seem like
better matches for the needs of real users. For my personal work,
support for MSVC6 is still important. If I need to use an FP library
with Boost.Python, I guess I'll be working with Phoenix. The
conversations that have come up during this review period have been
fascinating; it seems as though ideas new even to the LL authors have
been raised. Perhaps the process of defending a library through the
formal review process doesn't allow for the kind of deep consideration
of alternatives that I'm hoping for.

I hope this doesn't just leave everyone more confused,

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

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.

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. Although these should become the
same interface even if they are not the same underlying implementation, to
avoid user confusion. 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."

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.

  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.

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.

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.

   Yours,
  -Gary-