Re: [boost] Review: Lambda library - more technical analysis

From: Joachim Achtzehnter (joachim_at_[hidden])
Date: 2002-03-25 17:53:37

Asger Alstrup Nielsen wrote:
>
> Lambda Library is a 80% reimplementation of C++ inside C++.  There
> are restrictions and limitations in C++, and therefore the
> reimplementation is suboptimal in many places... C++ lacks a bunch
> of features, and therefore it is hard to solve the problem better
> than they have.

This is a crucial point. IMHO, the right solution in the long term is
for C++ to provide proper language support for this. The addition of
STL to the standard library has revolutionized the way C++ is used,
but it has also revealed a serious shortcoming of the language, and LL
is trying to work around this shortcoming.

> I have three major issues that I elaborate on in the following:
>
> 1) LL is trying to solve the wrong problem

This position is difficult to understand. In my view, LL provides the
best work-around for C++'s lack of direct support for lambda
expressions I have seen. It seems to be solving the right problem.

> 2) The problem can not be solved satisfactory. C++ does not
>    have the features needed to do this properly, and the result
>    is not complete, nor "clean".

Agree with the diagnosis, but my conclusions are different. Until C++
provides the required language support, there simply won't be a
completely satisfactory solution. The real solution is to support the
exact same language inside lambda expressions as outside (no need to
learn two languages). This won't ever be achieved as a pure library
solution. But in the meantime, until language support arrives, I'd
rather prefer a good band-aid solution over the current situation. Not
being able to define even simple functions inline is the biggest pain
in the butt in my work with C++.

> 3) In solving the problem, LL de-facto introduces a new
>   programming language inside C++, which tries to mirror
>   C++ itself as much as possible. This is questionable for
>   several reasons:
>    a) Study Common Lisp to see where this trend takes you.
>       If you have the energy to read the hundreds of pages
>       with one small programming language after the other
>       all inside the same language, I think you will discover
>       that you should think twice before introducing a new
>       language.

Here I don't follow you at all. First of all, Lisp does *not*
introduce a *new* language to support lambda expressions, so your
analogy doesn't seem to make sense.

Secondly, the ease with which one can invent new languages in Lisp is
one of its biggest strengths. The whole point of a high-level language
is to permit expressing the problem in terms that are as close to the
problem domain as possible. What can be more powerful than inventing
a complete custom language?

>    b) If you have to introduce a new programming language
>       in order to solve the problem, it might be worth it
>       to go for a different language which can be embedded
>       more nicely.

This seems to contradict an earlier statement. It would imply that you
need to learn two languages, even for simple things.

> Well, complex expressions take a long time to compile, the compiler
> might not be able to compile them due to template depth, and the poor
> error messages make it hard to write complex code. These problems
> lead the authors themselves to advise against writing complex
> lambda expressions.

True, but even in Lisp one tends to define named functions once a
certain complexity is reached. Also true, that one would prefer a more
general solution, but lacking language support, I have to come back to
my earlier statement: With LL one can do a lot more than is possible
now, and I think this is worth having.

> In addition, there is a very important restriction:
>
> You can not define named, local variables inside a lambda expression!

Agree. The way Phoenix introduces explicit variable names, in the
spirit of the traditional lambda formalism, seems a better (more
general) solution. But I'll admit that my exposure to Lisp may
influence me here.

> The end result, to me, seems to be this: While LL technically
> provides a way for you to write complex lambda expressions, the
> reality is that it is only practical for one-line expressions.

This is a slight overstatement. One can go beyond one-liners.

> So I'm left with a feeling that we are so close to getting the real
> thing,

Disagree strongly. We won't get close until there is language
support. I see LL (and Phoenix, etc.) as interim solutions, and I'd
rather have them now than later.

> - The syntax of control statements

Agree, such syntactic improvements are worth "stealing" from
Phoenix.

> - VC6 compatibility

Unfortunately, I'm also currently in a position where lack of VC6
support will prevent me from using it. But I don't consider this a
reason for rejecting the library. Its Microsoft's fault after all.

Joachim

-- 
work:     joachima_at_[hidden]   (http://www.netacquire.com)
private:  joachim_at_[hidden]          (http://www.kraut.ca)