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