From: Gary Powell (powellg_at_[hidden])
Date: 2002-03-18 11:21:33
> Bind issues aside, I my overall impression is that the library is
> I don't see for loops and try/catch blocks as necessary parts
> of a lambda library; of course this is only my personal opinion,
and I am
> free to not use the features I don't find appropriate, so this is
> major problem; it's only that this epic scope could prevent lambda
> being added to the standard library. ( Another feature I don't see
a need of
> is currying support. It seems added just because it's possible, not
> it solves a practical problem. I liked the original lean-and-mean
> from several years ago. :-) )
Second this. I can hardly imagine using of very complex function with
switch end exception handling expreseed as one expression in a
production code. What if I need to step into it in the debugger?
Though this is just my feeling, that need real usage to justify it.
Part of the reason to extend the Lambda library is to show that anonymous
functions should be added to the language. In order to allow anyone to even
simulate this idea we attempted to add as much of C++ to the lambda syntax
as is possible. I too hate the current error messages, and the debugging,
although with inline'ing off its not too bad.
In an earlier version we implemented _ALL_ of the STL algorithms into LL.
The reason being was that it should be possible to do iterate across a
matrix using for_each et.al. We can of course finish this work but are
waiting to see how this level is received. Our main complaint with the STL
algorithms was that as soon as things got in the slightest way complex
things start to get really hard. Lambda is one way to make it easier.
On the other hand we tried to keep each new layer of complexity to its own
include file so like everything else in C++, you only pay for what you use.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk