Comments on Smalltalk block closure designs, part 1
Stephan Rudlof
sr at evolgo.de
Wed Apr 25 21:15:34 UTC 2001
Dear Allen and other Squeakers!
Allen, I want to thank you for your interesting comments first!
In the following I try to give some 'mapping' of the rules given by Allen to
my proposal. This should lead to a better understanding (for me, too!) of the
differences between these approaches. I try to describe which elements in the
BCSBlockContexts draft correspond to these rules. Please note, that there has
just been an update of my draft (triggered by Andreas Raab).
Expression
'->'
means
'the former corresponds roughly to the following elements from "Draft for
Block Closure Semantics for Squeak v0.7.0"'
.
Allen Wirfs-Brock wrote:
<snipped much of very interesting stuff>
> I've now covered enough to explain how Smalltalk blocks with full closure
> semantics can be implemented an a way that never forces reification of the
> activation record stack:
>
> Allocate all arguments and temps that are not "captured" by blocks within
> stack allocated activation records.
-> blockCopy if needed; it is needed if there starts a second evaluation
before finishing the first one;
-> stack allocated activation records correspond to *some* of the indexable
fields of the created BCSBlockContexts;
> All variables that are subject to capture by blocks are explicitly
> allocated in heap allocated environment objects
-> nothing like that
> (or, if "read-only", copied into the block object).
-> same
> (only activations that have captured variables need allocate environment
> objects, except for the following rule)
> The activation of a method that contains blocks with up arrow returns
> always allocates a heap environment object.
> (it may be empty, in the sense that it contains no variable, but it must
> be allocated)
> Activation records reference ("point to") environment objects but
> environment objects never point to activation records.
> Environment objects and block objects may reference other environment objects.
-> there are no environment objects at all (for returning BCSBlockContexts
have a home pointer, see below),
-> outer temps reside in indexable fields of outer contexts,
-> outer temps are directly (oops for readonly vars) or indirectly (o/i pairs
for read/write vars) referenced by entries in indexable fields of actual
BCSBlockContext;
> A block (a closure) object references its enclosing environment(s) (but
> never the enclosing activation record(s))
-> there is the sender pointer to the next outer BCSBlockContext;
-> there is the home pointer to the MethodContext which has generated the
outmost BCSBlockContext (of the BCSBlockContext chain);
-> in addition outer contexts at arbitrary places in the BCSBlockContext chain
may be referenced by entries in the indexable fields of the actual context
(for read/write temps);
> A block object that implements an up arrow return captures a reference to
> the environment associated with its method activation.
> (This is used as the continuation marker)
-> home pointer
> An up arrow return is implemented by searching up the activation stack for
> an activation record whose environment reference is the same as the
> continuation marker of the returning bock. The activation stack is
> trimmed to that activation record and a return is forced.
> (If no activation record with that environment is found we have a
> #cannotReturn: situation)
-> just return to home sender
I hope I haven't missed important things!
>
> Enough for part #1, with luck I'll still be motivated to keep writing on
> part #2 tomorrow
>
> Allen
>
That'd be nice!
Greetings,
Stephan
--
Stephan Rudlof (sr at evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|