Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!decwrl!sun-barr!newstop!exodus!rbbb.Eng.Sun.COM!chased
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.std.c++
Subject: Re: Proposed: "closures"
Keywords: proposal, closures, function pointers
Message-ID: <11489@exodus.Eng.Sun.COM>
Date: 12 Apr 91 20:03:05 GMT
References: <1991Apr12.081539.22690@kestrel.edu>
Sender: news@exodus.Eng.Sun.COM
Distribution: comp.std.c++
Organization: Sun Microsystems, Mt. View, Ca.
Lines: 28

There's one more way to implement closures, though it is less workable
in this age of parameter-passing in registers and split (inconsistent)
instruction and data caches -- one can generate code at run time to
implement a closure, and this pass a "closure pointer" in the same
style currently used to implement a "function pointer".  Thomas Breuel
(sp?  tmb@prep.ai.mit.edu, I think) originally gave me this tip for
implementing nested functions in Modula-3, and it worked quite well
for the 68000.  David Keppel (pardo@cs.washington.edu) has been
exploring use of run-time code generation on machines with less
friendly caches.

And yes, I think closures are a good idea.  I have no special sympathy
for existing code that uses pointers to member functions; first, I've
never come across such code, and second, it wouldn't be the first time
that a change to the language broke existing code.  I'm certain that
I'd have more use for this than for (say) multiple inheritance (why
so?  because I've needed to use this a couple of times already and
simulated it clumsily, and because I haven't ever used multiple
inheritance, even though it is already in the language.)

Also, the implementation techniques suggested are not that bizarre --
consider what is typically done to implement multiple inheritance, or
what will be done to implement exceptions (it's either tricky, or you
lobotomize your optimizer, and it'll happen whenever you have a
stack-allocated object that has an associated destructor).

David Chase
Sun