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

From: Asger Alstrup Nielsen (alstrup_at_[hidden])
Date: 2002-03-26 15:27:55

First of all, I am very happy with the recent announcement from Jaakko
regarding a potential merging of Phoenix and LL in a future version 2, taking
the best of Phoenix into LL. This, I feel, is a very great step in the right
direction.

As such, I feel that one goal has been reached. Now, it's on to the next.

To explain this goal, I think it is helpful to relate it to the thread I
started, to which Joachim Achtzehnter kindly responded:

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

I feel it is crucial to differentiate the need for lambda *expressions* on one
hand, and the need for lambda *statements* on the other. I certainly see the
full need for full-blown lambda expressions (which is why it's great that the
expression support from Phoenix is adopted), but I have a hard time to see the
need for full-blown lambda statements.

LL is trying to solve both the expression and the statement problem. I think
this is wrong, and this is what I'm trying to express in my original mail.

First of all, I think it will be very difficult to do full-blown lambda
statements with the same syntax and semantics of C++ even in a future improved
C++. As it is, C++ already needs a very complex parser, and the semantics are
pretty hairy as well. If you throw in the ability to write arbitrary
expressions and statements at any expression and statement site in the
grammar, and do this recursively, I anticipate you raise the difficulty of
specification and implementation quite a lot.

But let us just assume for a moment that some wizard comes up with a simple
way to do this, despite the odds. In this situation, I would still be
reluctant to appreciate this. I find a limited set of features like
sequencing, assignment, and if-then-else useful, but switch-statements,
exceptions, while- and for-loops, and some of the rest seem wrong to me.

Part of the Boost reviewing process is to provide your evaluation of the
potential usefulness of the library. What is the potential usefulness of those
lambda statements?
I have not seen any convincing examples for when to use those features yet.

LL has surely illustrated the need for some more language support. The authors
mention typeof. typeof will surely make lambda *expression*s a lot simpler,
and all the type-deduction hoopla for this will likely be much simpler. So
this is great.
But how will typeof help make the exceptions, switch-statements, the for- and
while-loops, and the new/delete stuff better? What language support do you
need before you can make this better? It seems to me that you need some syntax
you can not get.
So I do not think it is fair to include those features with a reference to the
fact that they illustrate lack of language support. Yes, they do illustrate a
lack, but the lack is so great that it even illustrates that language support
for that is not around the corner.

This is in contrast to what the lambda *expressions* illustrate: With typeof
alone, we are practically there. And FWIW, typeof is probably already slated
for standardization, so this is finding is not unique to LL.

To put it short:

I do not think we should include all of LL because it illustrates that typeof
is a good idea. We already know that.

I do not think we should include all of LL because it provides band-aid style
lambda *statements*, because those are band-aids, will probably be that for a
long time, and are bad style anyway.

Now, fortunately the recent announcement from Jaakko gives me an opportunity
to open the door for accepting some of LL because it provides lambda
*expression*s at the same level as Phoenix. So I would be happy to accept LL
in version 2, provided the advanced lambda statement and exception support is
taken out.

I realize that all of this may sound more like bashing than constructive
critism to some. My goal is not to prevent LL from adoption for some
unspecified reason, even when great advances are announced. -- I am the only
one so far that has voted against, so this will not happen anyway.

But I am trying to make the rationale for LL inclusion more nuanced and
conscious by being extra critical. LL has tremendous impact. I think it will
help to be very critical in this situation.

So the ball is back in your court: Why should LL include the advanced
statement and exception support? I truly hope you can convince me that it is a
good idea, and that the needed language support to make it great is realistic
to achieve.

Greets,

Asger Alstrup Nielsen
P.S. Allow me to once more congratulate Jaakko and the others on making the
move towards Phoenix. That is very exciting.