Re: [boost] Review: lambda library

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-03-22 09:30:33

Interesting discussion. :-)

----- Original Message -----
From: "Asger Alstrup Nielsen" <alstrup_at_[hidden]>

> From a preliminary look, it seems to me that the Phoenix work is better
> than either LL or FACT!, both in terms of semantics and syntax.

I think that this conclusion is a bit premature. Phoenix is "cool." It uses
fancy operator overloads to "reinvent C++" and to define its own
metalanguage. This might be a good thing. We'll now for sure after several
years.

> 2) A more detailed semantic comparision with FACT!, Phoenix, and
> Phoenix's ancestor FC++ would be helpful.

FWIW, my opinion is that functional programming is best done in a functional
language. I understand the motivation behind FP C++ libraries, but IMHO the
C++ standard library doesn't need an academic functional programming library
or a Haskell prelude.

> 3) In particular, I would like a more detailed analysis of the relevance
> of scoping in the lambda expressions as FACT! (and Phoenix?) provides.
> As I understood Jörg Striegnitz, LL does not have scope.

It is trivial to introduce a scope in both Bind and Lambda using a helper
function object.

> 4) Additionally, an performance comparision with competitors would also
> be helpful.

I disagree. I've always held the somewhat idealistic view that we at Boost
"endorse" interface specifications (with reference implementations) and not
concrete libraries.

Besides, I regard Lambda (and Bind) as a _convenient shiorthand_ to define
_simple_ function objects inline. If you want performance, simply define the
same function object explicitly.

> 7) Practically, if FACT! and Phoenix are portable to VC6, while LL is
> not, this is worth considering.

Nothing is portable unless it has been ported.

In conclusion:

In my (biased) opinion, here is what should go into Boost:

A superset of the current Bind library that, in addition to bind()
expressions, supports operator overloads with the following semantics:

(x @ y)(V) = x(V) @ y(V), where @ is an operator, V is an argument vector,
C(V) = C, _k(V) = Vk, as already defined in the bind specification.
Optional: an if_then_else construct since operator?: cannot be overloaded,
but not if_then.

This is the baseline, non-controversial ET library that is actually quite
useful. The additional features are still immature; we need more experience
with them.