On 06/07/12 00:01, John Cowan wrote:
> Aaron W. Hsu scripsit:
>
>> This is not clear to me.  What about the dynamic extent in which the
>> thunk is evaluated? This affects parameters.
>
> That's true, but it's a general problem which we have to resolve.
> What are we going to do about code like this:
>
> (define foo (make-parameter 0))
> (define bar (delay (foo)))
> (parameterize ((foo 1)) (force bar))
>
> Does this return 0, 1, or either?  All the Schemes in my test suite that
> support SRFI 39 return 1.

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.

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. Although WG1 scheme doesn't offer any
way of creating threads or safely handling mutable state between them, I
don't think there's water in the argument that parallel promises
shouldn't be allowed without a way of handling mutable state
thread-safely, as WG1 code *might already be used in a WG2
implementation that has threads*, so a promise might well be forced in
an arbitrary thread anyway, unless the programmer knows the exact
situations in which their promises are used. In addition, the original
poster actually suggested that it be possible to specify "a hint" when
delaying that would enable parallel execution, rather than it being
impossible to avoid.

>> Additionally, there is no
>> gain to forking a thread at force time, because force must wait for the
>> return any ways.
>
> No, the idea is for `delay` to fork a thread and `force` to join it (unless
> the result is already cached).

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.

ABS

--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/

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