[no subject]

[PAM]

GLS@MIT-AI 05/27/78 17:09:59 Re: Cretinous Stack Groups
To: NIL at MIT-AI
CC: (BUG LISP) at MIT-AI, (BUG LISPM) at MIT-AI
Here is a proposed theory of "stack group/cretin" interactions.
This was worked out by DLW and me, with reference to the SL5 paper
in this month's CACM, starting also from the existing LISPM SG
implementation.  DLW worked out quite a bit of this, but I may take
liberties in emending it, so any inaccuracies are my fault.
Because I am not fond of "stack group" as the name of these entities,
I'll call them "cretins", and also choose completely terrible names
for the proposed functions, hoping that they will not become entrenched,
because I haven't given much thought to names that would meaningfully
reflect their high-level semantics.

A cretin must contain a certain amount of state; it has the control
stack and binding pdls for a process, and possibly much other stuff.
Here I will not talk at all about the binding disciplines, but only about
the control.
Let one slot of the state of a cretin be known as the "resumer".
This slot may be empty, or may point to another cretin, in which
case that cretin is presumably in a suspended state, waiting for a value
to carry on with.
Now when one cretin (a) wants to transfer control to another (b), it must
pass a value to it; it may or may not also want to pass a resumption
point.  If it (a) does, it may want the resumption point to be itself (a),
its own resumer (the resumer of a), or yet a third party (c).
Now if a does choose to pass a resumer to b, then it will be stored
in b's resumer slot for later reference.  The resumer slot of b must
be empty for this to occur (stipulation, to avoid losing information
and allow error-checking).  It is permissible, however, not to pass
b a resumption point when b'd resumer slot is empty; in this situation
b must be smart enough not to use its resumer slot.
We thus propose primitives of this sort:
(CRETIN-GO value cretin resumption)
	This transfers control to <cretin>, giving it <value>,
and passing it <resumption> to be put in its resumer slot.
Error if <cretin>'s resumer slot is not empty.
(CRETIN-GO value cretin)
	Transfers control to <cretin>, passing no resumption point.
(CRETIN-JRST value cretin)
	Transfers control to <cretin>, passing it my resumer as a resumption
point, and also clearing my resumer slot.  If I have no resumer (my slot
is already empty), then <cretin>'s slot will be made empty also (?).
(CRETIN-PUSHJ value cretin)
	Transfer control to <cretin>, passing myself as the resumption
point.
(CRETIN-POPJ value)
	Transfer control to the cretin in my resumption slot (error if
none), passing no resumption point.
(MY-RESUMER)
	Returns my resumer, and as a side-effect clears my resumer slot.
Useful for weird hacks.
(HIS-RESUMER cretin)
	Returns the resumer slot of <cretin>.
(CLOBBER-HIS-RESUMER cretin resumption)
	Clobbers <cretin>'s resumer slot.  NIL (i.e. ()) means make empty.
CLOBBER-MY-RESUMER??

Some of these are incredibly dirty, and others are more disciplined.
It is not hard to show that if things are initialized properly,
and only CRETIN-PUSHJ and CRETIN-POPJ are used, then nothing bad can
happen - no errors should be able to occur undetected.  Maybe
this also holds if CRETIN-JRST is added - this is intended as the
equivalent of the "JRST hack".  The otherrs allow for completely
general hair, such as may be necessary for time-slicing or distributed
processing kinds of deals.
Now transferring control to another cretin suspends the current one,
putting it into a state that awaits a value.  When eventually someone
else transfers to it, that value is returned as the value of the call
to CRETIN-PUSHJ or whatever.  Multiple-value versions of all of
the above can be worked out.



// 46 //