RE: [boost] Review: lambda library

From: Gary Powell (powellg_at_[hidden])
Date: 2002-03-22 17:41:33

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

I certainly believe that it is relevant to hold off inclusion for a few
months, if it turns out that a library needs a major reorganization in
order to assimilate new technology to break new grounds, and that it is
likely to occur within a relative short time-frame.
-------------------------------
We are not talking about new technology here. bind() was first written by
Jaakko in 1999. Peter D. made a clone of the original interface and expanded
it as he saw a new need, and got it added to boost, knowing full well that
the Lambda version was coming. People have had the benefit for the last 6
months of having a boost bind.

Phoenix if_()[].else_[] is syntax sugar, Not to put it too lightly. It is
still a cool idea, but again, its a forwarding proxy, and an interesting use
of the overload of [], not new technology.
Joel Please take this the way I mean it. I LIKE IT! ITS A COOL IDEA!

But the general rule of proposing a library is to freeze the features,
evaluate and critique. Not add in every new idea during the evaluation. Also
there can be a phase 2. Note that the random library was reworked to make it
better. Boost libraries are not static.

-------------
I requested an analysis to illustrate the technical differences between
the competing methods in order to uncover this fear. The fair answer was
that this was beyond the scope of the library, so therefore the
differences were not really relevant at the present time.
This is indeed a fair response -- there is only so much time and so many
things to do. But at the same time, it does not relieve my fear that the
proposed system is not the best foundation for a future system.
-------------------
Some how I think that this work is for the reviewers of the libraries, not
necessarily the developers. Get the code, look at it. We can answer
questions about our implementation, but its not fair to the developers of
other libraries to have me critique their code. They didn't propose their
libraries to boost. They are not under review.

--------------
So, while inclusion into Boost does not fix a library in stone, I
believe that you should consider the likelyhood of a major
reorganization within a reasonable timeframe as a factor for immediate
adoption.

If indeed it is likely that a major refactoring is coming, it is natural
to investigate if this should be done before inclusion or not.
--------------
Yes agreed, but no one is proposing a major refactoring of Lambda. We have
ideas but frankly it would do Lambda good to have some more users and their
feedback. We'd be glad to put up experimental interfaces, or help others
write them. But those interfaces should be judged later when they are
mature.

-----------------
Now, on one hand I hear is that the timeframe is not a few months,
because it took 3 years to get to where we are today. On the other hand,
I hear that scoping is easy, and could be done fast. So what are you
expected to think? At the same time, we are hearing that work is
underway to adopt new syntax from Phoenix. This is a major change in the
interface, and could itself warrant a second round of reviewing.
---------------
The 3 years is how long it took us to see the other possibilities, not how
long it took to type the code. We have refactored this library at least
twice already, without changing the user interface. It always takes less
time to rework something given that you have a working version of the thing,
and a defined interface. (Or to add new features to a well designed
library.)

One can accept lambda as is today, use it. And after this review period is
over, re-evaluate/re-implement the library without breaking any user code.
(Even though we don't as a group (boost) guarantee that interfaces will
remain static.

------------------
I draw the conclusion that the field is not mature yet, and a few months
of cooperation between the different parties could reap great benefits.
At least, it could help mature the field and reduce the uncertainty.
------------------
Yes, we have all been "cooperating" and "testing" and communicating. But we
also mostly have day jobs. So while Expression templates is moving and
generative programming is moving. LL interface has been the same for the
last year and a half.

-------------
Certainly, such instability should also affect the scope of the library.
If there are reasonable technical grounds to expect that certain parts
of the library might need changes in interface or major parts of the
implementation because of the advancing of the art, it is relevant to
take those parts out for now, if that is possible. (I don't know if this
is the case in LL, but I feel that this discussion is not restricted to
LL as such, but to the general problem of how to handle this situation
where you have to make a decision in a fast changing field.)
-------------
The library isn't unstable. And its not that Expression Templates themselves
are unstable. What is interesting are all the new ideas people have come up
with to use Expression Templates to solve problems for. i.e. Spirit etc.

-----------------
I guess I advocate that we should go more slowly. It has taken three
years until now, and while I can certainly understand that the authors
could use some recognition now to reload the batteries, I think the
recent developments and discussions already has done that. Things are
moving fast right now, and I'd like to see where things are heading
before I settle for a general direction.
----------------
Three years is already long time. How much slower must we go? I'm being
rhetorical but I'm serious, Lambda is ready for use now.

-----------------
What is the rush? Can't we wait a few months now that the action has
started and see where the art is going in this time-frame? If nothing
has happened in a few months, then great, LL will be adopted at that
time. The harm in such a postponing will be minimal, but I feel we'd
know so much more.
----------------
There is no rush, but we are done with phase 1 for boost.
ie. We ported the code to the boost libraries, (We used to use our own type
traits.) We are using the new Preprocess library. We wrote the documentation
for the users.

----------------------
Now, of course there is a small risk that we in a few months will be in
the same situation once: A lot of important progress has been made, and
a new version of the library is proposed for adoption. Then, a new bomb
is dropped, and inclusion is postponed because this warrants
investigation. Of course, you have to put down the foot down at some
point, but I don't feel we are at that point right now.
---------------------
This is just more FUD. Its difficult to understand why a library that works,
is well written, unique, fills a void, is documented, isn't good enough. I
can understand why an individual programmer or team might not choose to use
Lambda. It's a new technique, (in industry anyway) but its ready for boost.
Is boost ready for it??

   Yours,
   -Gary-