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.                 cowan@ccil.org
I could not.  --Great-Souled Sam                http://www.ccil.org/~cowan

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