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
> 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
> 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
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 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk