Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!hsi!stpstn!cox
From: cox@stpstn.UUCP (Brad Cox)
Newsgroups: comp.object
Subject: Re: code blocks (aka closures)
Message-ID: <5319@stpstn.UUCP>
Date: 3 Jul 90 16:13:08 GMT
References: <12396@june.cs.washington.edu> <1112@carol.fwi.uva.nl> <5305@stpstn.UUCP> <11002@alice.UUCP>
Reply-To: cox@stpstn.UUCP (Brad Cox)
Organization: Stepstone
Lines: 44

In article <11002@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes:
>The first problem is that the calling sequence has to be changed
>so that a function always has available the location of the appropriate
>stack frame of the lexically surrounding scope.

Andrew, thanks for your insightful analysis of the issues surrounding
the addition of Smalltalk Blocks, Closures, or Actions to C. In my
article which triggered this topic, I was referring to a much simpler
and less powerful scheme that can be implemented on vanilla C by not
duplicating Smalltalk continuations exactly. As you point out, maintaining
the location of the stack frame that instantiated the block is intractible
because of C's stack management philosophy (however see below). My
(simplified, not as powerful) scheme avoids this by simply evaluating
local scope variables at block *instantiation* time, rather than block
*invocation* time as in Smalltalk. At instantiation time, the arguments
are still in scope, and can be simply copied and held for future use
as instance variables of the block that is being instantiated.

As for doing the job right, there are intriguing claims in an article in
the ACM SigPlan 90 Conference on Programming Language Design and 
Implementation, "Representing Control in the Presence of First-class 
Continuations", by Robert Hieb et all of Indiana University. It 
describes a stack management philosophy that is claimed to be <faster than?
as fast as? almost as fast as? within a constant factor of? within an order
of magnitude of?> C's traditional approach.

The article is quite readable, and I believe compelling.  Although I'm
aware of the difficulty of adopting a new stack management paradigm within
C, I'm also a believer that digging our way out of the software crisis 
will *require* even higher level styles of object-oriented programming
than we've seen in either C++ (gate/block level objects) or Objective-C 
(chip-level objects).

I'm particularly enamored of coroutine-based (card-level) objects as
in LabView, Metaphor, or Fabrik, since by supporting an OO paradigm that
even non-programmers can understand, we might solve the programmer shortage 
as the telephone operator shortage was once solved, by turning *everyone* 
into programmers. But this will eventually require doing something about
C's substructure, whereas Bjarne and I have been living with that and
building superstructures.
-- 

Brad Cox; cox@stepstone.com; CI$ 71230,647; 203 426 1875
The Stepstone Corporation; 75 Glen Road; Sandy Hook CT 06482