[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Scheme-reports] Promises that force themselves



On Sat, Feb 9, 2013 at 2:13 PM, Alan Manuel Gloria <almkglor@x> wrote:
Anyway, what would the following yield?

(define x 0)
(define p
  (delay
    (if (= x 5)
      x
      (begin
        (set! x (+ x 1))
        (force p)
        (set! x (+ x 1))
        x))))

(force p) => 10 (maybe?)
(force p) => ????

So: in case of a recursion, does it return the same value as the first
returning external (force p) - which yields 10 - or the same value as
the first returning internal (force p) - which (I think) should yield
5?

You've misunderstood the specification (which is all the more
reason for us to make this clear).  When the promise is forced,
if the result has not already been computed, the thunk is evaluated.
Then, if somehow the result had been computed via the thunk,
we discard that result and return the pre-computed value.

So forcing the promise _always_ returns the same value,
in this case 5.  x will have been set to 10, though.

You know, I don't really know of a good use in applications of
re-entrant promises.
 
There are two questions to ask.  First, is the recursive
semantics truly useless?  We can't say that it must be
so just because we haven't used it personally (at least I'm
fairly sure I haven't).  The second question is, does it hurt
to have this in the language?  The alternate specification
would be something like

  It is an error if forcing a promise causes the same
  promise to be forced again, either directly or indirectly.

So the result is that users lose a (possibly useless) feature,
and you gain a wider range of implementation strategies.

Normally the practical approach is to provide the variant
you want in a new library in the large language, encourage
people to use that, and if it gains overwhelming acceptance
we can consider changing the core semantics.  This is
what we plan to do with call/cc vs delimited continuations.

This won't work here.  There's no incentive for users to
switch since they only lose a feature, and gain nothing.

Instead, if you're serious about this, I think your best
approach is to lobby implementors.  Convince them
the benefits of your implementation strategy outweigh
the chance that people might actually use reentrant
promises.

The Racket implementors already agree with you.
The example you posted gives the following error:

force: reentrant promise p

-- 
Alex

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports