Alex Shinn scripsit:

> >> # This behavior may be implemented in a variety of ways,
> >> # including the return of a thunk which `force` will evaluate
> >> # to the creation of a background thread to do the computation.

I blundered here:  the intended wording is:

> >> # This behavior may be implemented in a variety of ways,
> >> # including the return of a thunk which `force` will evaluate,
> >> # or even the creation of a background thread to do the computation.

Thunks and background threads were meant to be non-exclusive alternatives.
I started out writing "from...to", intended to change it to "including...or",
and wound up with "including...to".

I have also added this wording to `force`:

# If the value of the promise depends on any parameter whose value is
# different when the promise is forced for the first time, the result is
# unspecified.

Please let me know if you object to the presence of either note.

> If the compiler could prove that the delayed expression were
> referentially transparent and either independent of dynamic
> extent or guaranteed to be forced in a known extent (e.g. the
> same one as the promise creation) then it would be possible
> to run it pre-force in a separate thread (with some limits to prevent
> infinite thread creation).  The same logic could be applied to
> run e.g. map in multiple threads - even trivially on top of this
> delay:

Quite so.

> But this is the work of a smart compiler working within the
> existing definition of delay/force, so it doesn't bear mentioning
> in the standard.

I think it's worth mentioning in order to point out that people shouldn't
depend on the thunk behavior.

> I agree with Aaron that programmers should explicitly use
> something like futures for this case, and look forward to
> them in WG2.

I agree.

--
LEAR: Dost thou call me fool, boy?      John Cowan
FOOL: All thy other titles              http://www.ccil.org/~cowan
             thou hast given away:      cowan@ccil.org
      That thou wast born with.

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