RE: [boost] Review: lambda library

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2002-03-22 05:53:41

> So the goal is not to define a functional language within C++,
> and change the way of programming C++ entirely. There are languages
> far better suited for functional programming.
> (See FC++ for an approach closer to this goal.)

This is naturally the reason for many of the design decisions of LL. I
have respect for this position, and can sympathize with it.
As I understand you, the goal is not Lambda Expressions as known from
functional programming. Your goal is to provide a way to write anonymous
functions with basically all C++ features. In other words, your goal is
to maintain an imperative flavour, and make some tasks much easier to
solve.

On this basis, I feel that the library could have a better name. I don't
know what a better name could be, but I think it would be relevant to
consider a different one because I think the current one does not
adequately convey the intention of the library. When I hear "Lambda
library" I immediately get a set of expectations, and when I find that
these are not fulfilled, I am disappointed, even though the work itself
is excellent.

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.

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

To this, Jaako responds:
> There are languages far better suited for functional programming.
> (See FC++ for an approach closer to this goal.)

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.

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.

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.

Concretely, I don't think we have seen the best yet.

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.

Now I ask myself: Which scenario will provide the best library the
fastest?

My personal guess is 3, and that is why I do not vote for acceptance of
the current LL.

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.

- Introduce the syntax from Phoenix for control constructs

They are easier to read, and thus I expect this will prevents errors.

Thank you,

Asger Alstrup Nielsen