John Cowan <cowan@mercury.ccil.org> writes:

> Duncan Steele scripsit:
>>
>> I think it would be great for there to be a way to give an (optional)
>> hint to the interpreter/compiler to evaluate (delay ) ed expressions
>> in a background thread.  I assume that the lion's share of threading
>> support will be in R7RS-large, but with the trend of rapidly increasing
>> core counts I think that parallelism in some form must be tackled by
>> any serious language at the language level, and not delegated to its
>> standard library.
>
> It seems clear that having `delay` spawn a background thread is consistent
> with the R5RS/R7RS definition of `delay`, so I have added the following
> editorial remark:
>
> # 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.

This has the potential to break existing code for at least two reasons:

(1) It means that the delayed expression may be evaluated even if the
promise is never forced.  Therefore, programs which are designed with
the assumption that unforced promises will never be evaluated will do a
lot of unnecessary computation and possibly become unusable.

(2) It means that if the delayed expression mutates any shared state,
thread synchronization primitives will now be needed.  Since such
primitives are not present in R7RS-small, it will be impossible to use
'delay' and 'force' in a portable R7RS-small program.  Even if such
primitives are added, it means that portable programs will need to
assume that such (very expensive) synchronization primitives must be
used.

     Mark

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