RE: [boost] Review: lambda library

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

---------------
Within the stated scope of the library, LL is certainly great. Jeremy
Siek also points out that it is unfair to vote against a library on the
grounds that there are better alternatives in the horizon. Boost simply
does not work that way.
--------------------------------
Actually there have been a number of libraries which have been accepted
based on the fact that they have been submitted and are the best so far. Yet
there are others for which it was decided to hold off. There is no hard and
fast rule about this.

----------------------------------
So how can I justify my position?

I think that the recent developments has shown that it is possible to
reach the different goal of introducing functional programming in a more
pure form into C++, and at the same time fulfill the goal of LL.
I believe it is technically possible to construct a system that allows
both the imperative style of anonymous functions, and the functional
style of more pure functional composition. Standard ML combines these
aspects, so it's a question of getting some of standard ML inside C++.
----------------------------------
While this may be the case, it is not a trivial exercise to write a full
expression template aware library. I've been working on these since late
1998. LL has been in process since the middle of 2000.

-----------------------------------
Well, I think it is needed and possible for C++ to be competitive in
this area, because C++ has the performance, the installation base, the
interoperability, and the compilers.
----------------------------------
We are still missing some core language support. Typeof to really make C++
competitive. Also compilers, including KCC are not up to the task _yet_.

-------------------------------
Concretely, Phoenix seems to be reaching this goal. Yes, Phoenix is not
ready for submitting to Boost yet, and Joel has not stated whether this
is his intention or not. Therefore this alone is not enough to dismiss a
mature library with a different scope, because there is a real risk that
an alleged better option will never be submitted for Boost.
------------------------------
Here, I must agree with Jeremy. No work including LL is "final" "finished"
the best that will ever be. So if/when Phoenix is ready for boost
submission. Then we can judge. It is not fair to judge a given working
library against one that is still as young as Phoenix.

----------------------------------
My personal judgement is that it is realistic, within a time frame of
maybe half a year to a year, that some other library will be able to
reach the goal of introducing a lambda library of the kind mentioned
above for Boost inclusion, that also fulfills the goals of the current
LL.
---------------------------------
So why should everyone else wait 1.5 years for another "better" library to
come out? A new one won't break existing code using LL. We are not proposing
to change the C++ Standard, only offering a very useful library that has had
a lot of work put into it. That is reasonably well tested and to us seems
very useful as is.

-----------------------------
Concretely, I don't think we have seen the best yet.
----------------------------
I agree here. Yet to deny users a chance to use the best current existing
practice merely because something better is coming is IMO, a poor choice for
rejecting this library.

-----------------------------
So therefore it is relevant for me to consider what solution we will
have in X months. In this context, I think it would be helpful if the
authors of LL stated whether they, in the future developments, intend to
increase the scope of their library to reach such goals. If so, what
impact could this have on the technical solution they have today?

There are a number of scenarios:

1) LL is accepted now, but the scope remains the same. When the field is
mature, a competing library is submitted, and accepted. LL becomes
depredated.

2) LL is accepted now, and over time, the scope is increased to reach
the funcional goal as well. From the preliminary statements from Joel,
it seems that it is not easy for outsiders to make this change to the LL
technology base. I personally fear that the current technology base, and
the need for backwards compatibility, would prevent this scenario from
developing into the best possible solution.

3) LL is rejected now, on the grounds that the field is immature. We
wait X months for an alleged better library that might never appear.
---------------------------
I'd go with #2. The same way we are doing with "Threads." It works, let
people use it. Add functional programming to it if you want it, see how that
works. If you _REALLY_ like it and use it, add it, propose a new one etc.

Lambda may be fairly mature, but it is not static. We can always push out a
version 2.

------------------------
Now I ask myself: Which scenario will provide the best library the
fastest?
------------------------
My only comment to this, is, if you help, things will get done faster. If
not I have a day job as does Jaakko, so it will take longer. Although it
looks like Joel has a lot of energy and his help/ideas may make things go
farther faster.

----------------------
My personal guess is 3, and that is why I do not vote for acceptance of
the current LL.
-----------------------
That's ok. While I do not agree with your reasoning, I understand your point
of view here.

-------------------
Now, to be constructive in the case that LL is adopted now, allow me to
suggest the following changes that I feel fall within the scope of the
current LL:

- Change the default arity checking to be weak

This just seems more practical, even at the risk of loosing some safety.
--------------------
This is under discussion between others on this thread, and so far I haven't
seen a convincing argument. However, a number of choices to make this
available have been proposed, and one of them seems appropriate.

-------------------
- Introduce the syntax from Phoenix for control constructs

They are easier to read, and thus I expect this will prevents errors.
------------------
Joel, Jaakko and I are messing around with this. It seems a viable
alternative. I'm not sure it will lead to fewer errors, but it appears that
it can be built on top of the existing LL structure with little if any
penalty in either compile time or runtime. (further testing will confirm
this this.)

If I had thought this syntax up myself LL would already have it. As it is, I
want to be sure it doesn't break anything already working. Although there
are differing opinions as to whether this syntax is really better.

Thank you,
-----------------
You're welcome and all your comments are very much appreciated. I firmly
believe that the discussions on LL both will make it better and lead to more
interesting ideas in this area.

 Yours,
 -Gary-