RE: [boost] Review: lambda library

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2002-03-22 14:46:11

> >If any of these scenarios are realistic, then it seems to be that it
> >could pay off to hold the horse for this timeframe.
> 
> 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.

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.

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.

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.

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.

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

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.

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.

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.

Greets,

Asger Alstrup