Semantics of DELAY

[Morris Katz <mkatz@garlic.stanford.edu>]

   Date: Tue, 23 Jul 91 12:09:19 -0700
   From: William Clinger <will@cs.uoregon.edu>

   Feeley suggests that we should consider repairing the
   specification by adopting one or both of:

     (1)  It is an error for the body to return
	  more than once.
     (2)  It is an error if the body is entered
	  more than once.

   As motivation, Feeley cites an implementation in
   which promises are spliced out at GC time and complains
   that this isn't a legal implementation technique if
   DELAY forms can be returned from multiple times.  Well,
   that isn't true.  The implementation technique remains
   legal so long as the value obtained by forcing a promise
   is constant.

   I therefore suggest that we should require all uses
   of FORCE on any given promise to return the same value,
   while relaxing the requirement that the body of a
   promise be entered at most once.  If this is considered
   unreasonable, I would agree with a proposal in which all
   uses of FORCE on any given promise must return the same
   value, but it is an error for the body of a promise to
   be entered more than once.

   I see no particular problem with allowing the body to
   return more than once provided all FORCEs return the
   same value.  All other expression bodies in Scheme can
   return more than once, so why should the bodies of DELAY
   expressions be different?

I would suggest including a slightly less restrictive wording in RnRS.  The
reason is that I would like to leave open the possibility of experimenting with
a semantics in which a throw back into the body of a promise which returned a
new value would reset the value returned by force.  In such a semantics, the
body of the promise would only be executed the first time force was called for
that promise.  This would create the initial return value for force (assuming
the promise returned a value as opposed to performing a throw out of the
promise code).  All subsequent forces would return this value unless an
intervening throw into the promise body were performed.  

There are many other varients of force/delay + call/cc which are possible.
This combinatination offeatures shows marked similarity to futures + call/cc on
which I wrote a paper for L&FP '90.  The issues here a re very complex and I
would hate to see use standardize on a less than optimal solution before the
issues are properly understood.  

How about if we specify the semantics when their are neither throws into or out
of the promise body and leave the semantics in the presence of such throws
unspecified.
--------------------
Morry Katz
katz@cs.stanford.edu
--------------------