On Sat, Feb 9, 2013 at 2:13 PM, Alan Manuel Gloria <[email protected]>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 [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
