Re: [boost] Review: lambda library

From: joel de guzman (djowel_at_[hidden])
Date: 2002-03-22 11:08:00

----- Original Message -----
From: "Peter Dimov" :

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

I truly hope people will look beyond the syntax.

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

Please elaborate?

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

I agree.

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

Agreed.

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

This is the same motivation behind phoenix. All modules above primitives
and composite can in fact be regarded as extensions.

Regards,
--Joel