That's up to whoever decides to write up a proposal. I was just
throwing out a few vague ideas.

Attention: although I said class, as I was looking at it then, I was
really thinking of it as more of a temporary object of class type -- an
object, rather than a type. In that case, of course, new is
irrelevant.

The idea of considering it a class is interesting. (I don't know why I
was thinking object.) If it is a class, however, then we need some way
of immediately constructing a temporary object, when that is what we
want. If we don't support lambda functions, the answer is obvious:
lambda() ... (Note that there is no way to provide a constructor for a
lambda class, since it doesn't have a name. Maybe something should be
considered for that as well.)

Given that I conceived lambda as deriving from a special class
__local_context, which made the local variables visible, I'm not sure
that supporting new is a good idea:-). On the other hand, I have a
couple of functions taking auto_ptr<T> where using local variables in
the T could be useful in some cases.

Some more rope:-). But something which I guess has to be considered.

If lambda is a class :

new lambda : Base {
lambda() { x_ = x ; }
// ...
} ;

?

Supporting destructors seems even more useful.

That's my feelings exactly:-). Note the context I was responding in.
And my later posting, developing some of the ideas around lambda classes.


Sounds like a good idea. So now what do I have to write to get a temporary.


Agreed. Except that if lamda is a type, the syntax is invalid, because
you haven't got an object, and if it is an object, then things like new
and local named variables are out. And allowing it to be both sounds
to
me like a perfect recepe for more of the declaration/expression
ambiguity problems we know and love so well.

Anyhow, I'm now convinced that it should be a type. But I'm still
convinced that it should be a temporary object. And I'm very open to
any ideas as to how we can distinguish between the two uses.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Probably.

My posting was not meant to be taken as a concrete proposal. More just
brainstorming. I realize that if anyone is interested, it would take a
LOT more work to firm it up into something which could even be
considered as a possible proposal.

--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

david abrahams

So then just bind it to an auto&, and it will persist.

One thing that I think has been overlooked is that there should be a
syntax for lambdas that's as convenient and expressive as the current
library solutions. If you have to write anything as complicated as:

lambda (x, y) { return x + y; }

instead of:

_1 + _2

I think we'll be taking a lateral -- rather than a forward -- step.

--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

thorsten ottosen

| > <kanze@gabi-soft.fr> wrote in message
| > | IMHO, adding lambda classes to C++ would not be too difficult. A
| > | lambda class expression defines a temporary object; about the only
| > | problem I can see off hand is defining the lifetime of this object. |
| > why not make it a stack object of implementation defined type?
|
| That's what I thought I was suggesting. The question remains
| concerning
| it's lifetime. Basically, my tendency would be to make it a temporary,
| with lifetime extending to the end of the full expression. But there
| are uses where it is interesting to have an object with the lifetime of
| a local variable.

ok, I guess I meant local variable then.

| Another interesting structure could be:
| cleanup <function-body> ;
| which would create an unnamed local variable (not a temporary, so
| lifetime until the normal end of scope) of type:
| struct <anon> : __local_context | {
| ~<anon> <function-body> // A destructor.
| }
|
| But these are just vague ideas for the moment.

yeah, maybe if we consider a tool like scope guard, then
we can just create a cleaup functions as seperate anonymous functions:

ScopeGuard cleanup = MakeGuard( lambda() { foo(); } );

-Thorsten

--
Thorsten Ottosen
----------------------------
Dezide Aps -- Intelligent Customer Support:
www.dezide.com

Aalborg University --- Decision Support Systems:
http://www.cs.aau.dk/index2.php?content=Research/bss

C++ Boost:
www.boost.org

C++ Standard:
http://www.open-std.org/JTC1/SC22/WG21/

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

terje sletteb=f8

Hm, how about omitting the word "lambda", as well:

class { ... }
class : public X { ...}
void (...) { ... }

I find it rather natural to express a class without a name, as... a class
without a name. Same for function (this syntax for lambda functions was
discussed at an ACCU mailing list (effective-cpp) a while back, and was
received generally favourably. That also went for the following).

In cases where the function-notation may be ambiguous (or needing potential
lookahead, to distinguish what it is), one might reuse "inline" to
disambiguate. E.g.:

generate_n(out, count, int() { return rand() % 2; }); // "int()" has a
well-defined meaning in C++

generate_n(out, count, inline int() { return rand() % 2; }); // Now
unambiguous

Regards,

Terje

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

james kanze

The thought occurred to me. For various personal reasons, I'm not as
active in standardization as I once was, so I don't know what the
current status is -- I'm unaware of this auto, for example, and while I
do know that there will be something along the lines of typeof, I
couldn't figure out how to make it work, and I was also stymied by the
fact that you can't bind a temporary to a reference to non const (and
some of the uses I can think of would require non-const).


That's a good point. In most of the uses I would have had for his in
the past, it would have been irrelevant, in that I needed a specific
base class as well.

That said, I think I rather prefer that some explicit sign be present
that I'm using a lambda. Although I agree that something lighter than
what we've currently been talking about would be an improvement for
small things like the above. If the function has any real length, then
you probably want to give the parameters explicit names. But then, if
the function has any real length, you probably want to split it out into
another function/class anyway -- my experience with anonymous inner
classes in Java taught me that unless they are very, very short, they
quickly lead to totally unreadable code.

(And as you can probably gather from the above, I'm still very much in
the brainstorming mode. Just a lot of vague, sometimes conflicting
ideas for the moment.)

--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre S=E9mard, 78210 St.-Cyr-l'=C9cole, France +33 (0)1 30 23 00 34

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

maciej sobczak

Depends.
The _1, _2, ... names tell me nothing about their meaning. Looks more
like an assembly (and even before macros were invented for assembly)
than a language for writing clear and understandable code.

I want to name things which I use. This means that some language notion
of name declaration is in order. The example with:

lambda(x, y) { return x + y; }

is quite clear, because there is a place for naming (declaring) things
and a place for using things.

This may prove really good when you write lambda expressions as a result
of moving code around. Even better - it makes it easier to refactor
lambdas into normal functions if such a needs arises. The cryptic _1,
_2, etc. force me to rewrite the code when moving it to lambda or back.

What about:

int (int x, int y) { return x + y; }

It is even longer, but specifying types (especially the return type) is
what enables me to use lambda expressions with overloaded targets.

--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

dave ohearn

Yes, please. It's worth quoting _Structure and Interpretation of
Computer Programs_ in regards to this word "lambda",

"It would be clearer and less intimidating to people learning Lisp if a
name more obvious than lambda, such as make-procedure, were used. But
the convention is firmly entrenched. The notation is adopted from the
[lambda] calculus, ..." Page 63, footnote 53. (I have forgotton how to
form a citation properly...)

C++ has a fine tradition of eschewing arcane terminology when it is of
no value. If "method" rates a 7 on the arcane-o-meter and "subclass"
rates perhaps a 4, "lambda" is easily in the 15+ range. There is just
no need to burden students of C++ with historical sidebars about it.
--
Dave O'Hearn


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

david abrahams

Neither does the symbol '{' ... until you learn what it means in C++.
I'm not attached to those particular symbols, you understand. But if
lambdas are forced to be much more verbose than this they often won't be
worth using. The whole point is to have something concise you can drop
in without interrupting the flow of a function.


Ever tried a language that tries to make it possible to program in
"plain English?" <shiver>


Yes, that's very clear, and there is a place for named lambda variables.
But it's often overkill.


No they don't.

char f(int _1, char* _2) { return _2[_1]; }

How exactly would you create such an overload set? Example, please!


--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

gabriel dos reis

Maciej Sobczak <no.spam@no.spam.com> writes:

| > One thing that I think has been overlooked is that there should be a
| > syntax for lambdas that's as convenient and expressive as the current
| > library solutions. If you have to write anything as complicated as:
| >
| > lambda (x, y) { return x + y; }
| >
| > instead of:
| >
| > _1 + _2
| >
| > I think we'll be taking a lateral -- rather than a forward -- step.
|
| Depends.
| The _1, _2, ... names tell me nothing about their meaning. Looks more
| like an assembly (and even before macros were invented for assembly)
| than a language for writing clear and understandable code.

You must be alone :-) :-)

| I want to name things which I use. This means that some language notion
| of name declaration is in order. The example with:
|
| lambda(x, y) { return x + y; }
|
| is quite clear, because there is a place for naming (declaring) things
| and a place for using things.

In the paper "generalizing overloading for C++ 2000", it is argued
that we don't need hard-to-read long names and that multi-character
names are a relic of languages that relied heavily on global names and
encouraged overly-large scopes. I guess the proposed notation _<n>
has something to it :-)

Wel,, yes, I do want a clear mark that I'm using a lambda and have a
choice of the name I'll use.


|
| This may prove really good when you write lambda expressions as a result
| of moving code around. Even better - it makes it easier to refactor
| lambdas into normal functions if such a needs arises. The cryptic _1,
| _2, etc. force me to rewrite the code when moving it to lambda or back.
|
| What about:
|
| int (int x, int y) { return x + y; }
|
| It is even longer, but specifying types (especially the return type) is
| what enables me to use lambda expressions with overloaded targets.

It may probably introduce some parsing oroblems.
Byt, I would go even further and drop the "return" stuff.

--
Gabriel Dos Reis
gdr@integrable-solutions.net

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]