RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++

RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++

[Alexander Bottema]

It is interesting to see that they are trying to implement closures in
C++, something I wanted for a long time. Unfortunately, I don't think it
is useful without having a proper garbage collector. If you read the
specification (5.2) you can see it is something they struggle with. I
think it is time that they added garbage collection to C++ as the
default memory allocation strategy like all other high-level languages.
If we could restrict the semantics of C++ on how we use pointers then we
might be able to implement an efficient generational garbage collector
(e.g. a three generation based collector as in Microsoft .NET). An
alternative would be to use a conservative collector (such as Boehm),
but then there are less chances to do garbage collection optimizations
at compile-time.

Alexander

-----Original Message-----
From: caml-list-bounces@yquem.inria.fr
[mailto:caml-list-bounces@yquem.inria.fr] On Behalf Of Eijiro Sumii
Sent: Friday, March 17, 2006 5:08 AM
To: Caml List
Cc: Eijiro Sumii
Subject: [Caml-list] Stroustrup et al. propose to introduce
"lambdaclosures" in C++

Hi,

A friend of mine informed me of this report

    Lambda expressions and closures for C++
    Jeremiah Willcock, Jaakko Jarvi, Doug Gregor, Bjarne Stroustrup,
Andrew Lumsdaine
    2006-02-26
    http://public.research.att.com/~bs/N1968-lambda-expressions.pdf

and I thought you might be interested.  (I searched a little and
didn't find any discussion on this report in this list.)

A few highlights:

----------------------------------------------------------------------

    We propose to extend the C++ language with lambda expressions, and
define the semantics of these unnamed local functions via translation
to closures: function objects implemented using local classes.

...

    void f() {
      int sum = 0;
      for each(a.begin(), a.end(),
        <>(int x) -> int extern(sum) {return sum += x;});
    }

...

    2.1 Omitting the return type
    The return type of a lambda expression can be omitted if the body
of the lambda function contains at most one return statement.

----------------------------------------------------------------------

Enjoy:-),

        Eijiro

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Stroustrup et al. propose to introduce "lambdaclosures" in C++

[skaller]

On Fri, 2006-03-17 at 09:12 -0500, Alexander Bottema wrote:
> It is interesting to see that they are trying to implement closures in
> C++, something I wanted for a long time.

I proposed this YEARS ago (along with Fergus Henderson).
No one seemed to know what they were for. 
Stroustrup neglected to mention this :)

In any case, Felix implements this for C++ already,
only does it properly -- unlike the weak proposal of N1968.

>  Unfortunately, I don't think it
> is useful without having a proper garbage collector. 

It is. You should note gcc has provided anonymous functions
for donkey's years for C. The caveat is obvious .. you can't
use the function after the stack frame it is bound to has
been popped off the stack. 

This is no different to not being allowed to return a pointer
to a local variable.

> If you read the
> specification (5.2) you can see it is something they struggle with. I
> think it is time that they added garbage collection to C++ as the
> default memory allocation strategy like all other high-level languages.

It isn't possible. And Boehm doesn't play so well with RAII.

The way it is done with C++/CLI and Felix works, but is still
difficult. In both cases new constructions are required,
with distinct semantics.

Felix is much smarter than C++/CLI since closures are standard,
but the optimiser knows when it can reduce to ordinary C
functions.

My belief at the moment is that an advanced generational 
collector isn't appropriate for C++: it would yield WORSE
results than a naive collector.

For a start, C++ is heavily pointer based, so compaction
is fraught with difficulties. Felix actually does provide
compaction (and so far it proves slower to allocate
in a linear arena than just calling malloc :)

Secondly, C++ is multi-thread capable and no one would give
that up for a collector.

Thirdly, C++ is still imperative, and many people
use the OO features quite heavily. Thus, write barriers
would have a serious performance impact, not to mention
code bloat.

Fourthly, as Stroustrup pointed out C++ tends to spawn
a small number of large objects, rather than a lot of
small objects, and furthermore the RAII features mean
manual deletion is often simple and better: not all
structures are capable of supporting cycles. 

And finally, advanced collectors just don't work so
well with pointers that move around. Stuff isn't boxed,
and pointers run around inside objects. So reachability
is very expensive to compute, compared to say Ocaml,
where every pointer points at the head of a heap object.

Even if C++ bans disguising pointers in ints, etc,
it will be very hard to create an exact collector
for a language that supports so many ways of aliasing,
and conservative collectors just aren't the advanced
generational kind you'd want in a functional language.

So IMHO .. C++ is never going to have any kind of
advanced collector: it just wouldn't work.

It also seems pointless -- if you want GC and type
inference and other nice stuff .. just use C# version 2.
Just don't expect it to be fast :)

-- 
John Skaller <skaller at users dot sourceforge dot net>
Async PL, Realtime software consultants
Checkout Felix: http://felix.sourceforge.net