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: [email protected] That thou wast born with. _______________________________________________ Scheme-reports mailing list [email protected] http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports
