On Thu, 2012-06-07 at 15:30 -0400, John Cowan wrote: > Please let me know if you object to the presence of either note. At the moment, I am inclined to object to both. The idea behind DELAY and FORCE is that at some point you are intentionally saying, "Do not evaluate this yet," and at some later point, "Now you should evaluate this." I think the terms DELAY and FORCE strongly suggest this interpretation, and as you pointed out, the semantics of all major implementations coincides with this. Additionally, creating a large unspecified set of valid uses of force (involving parameters) just to enable an optimization that is likely to be undesirable in many cases, and for which a perfectly valid and more obvious solution exists, reduces the value of DELAY and FORCE to an extent that I find unappealing. I do not think we should use space to mention this issue, but implementations are obviously free to use threads to evaluate suitable delayed expressions if they follow the correct behavior, as Alex suggested. Thus, instead, I would prefer to clarify that a forced thunk should evaluate in a context equivalent to the dynamic context (including exception handlers and parameters) of the call to force which first requested the delayed expression's value. -- Aaron W. Hsu | arcfide@x | http://www.sacrideo.us Programming is just another word for the lost art of thinking.
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Scheme-reports mailing list Scheme-reports@x http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports