Alaric Snell-Pym scripsit: > Indeed. Which also makes it difficult for us to do the "right thing" and > state that delay should capture its dynamic state in the promise.
It's not clear to me whether it *is* the right thing. Ordinary closures do not close over the dynamic environment, although other Lisps have had such closures. > Users of delay/force who assume things about the dynamic environment in > effect are already in foot-shooting territory, probably along with > people who mutate state in them. Indeed. Either that, or we should just say that delay/force *must* work like a closure. > A better implementation approach would probably be to have a pool of > low-priority "idle threads" that, when scheduled, pick pending promises > from a (priority?) queue and force them. That is how Racket futures work: there is a single thread that does all future-creating, future-forcing, and mutation, and then there are p - 1 threads (where p = number of processors) that actually execute the body of the futures. -- You escaped them by the will-death John Cowan and the Way of the Black Wheel. [email protected] I could not. --Great-Souled Sam http://www.ccil.org/~cowan _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
