On Fri, Jun 29, 2012 at 10:15 AM, Eli Barzilay <eli@barzilay.org> wrote: > A few minutes ago, Alex Shinn wrote: >> On Fri, Jun 29, 2012 at 9:32 AM, Eli Barzilay <eli@barzilay.org> wrote: >> > Yesterday, Alex Shinn wrote: >> >> On Thu, Jun 28, 2012 at 1:39 AM, Eli Barzilay <eli@barzilay.org> wrote: >> >> > A few minutes ago, Alex Shinn wrote: >> >> >> On Thu, Jun 28, 2012 at 1:12 AM, Eli Barzilay <eli@barzilay.org> wrote: >> >> >> > With both present, there is an easy way to remember which one to >> >> >> > choose: `lazy'. >> >> >> >> >> >> `delay' is useful for many other things besides streams, where >> >> >> `lazy' would not be applicable. >> >> > >> >> > For example...? >> >> >> >> Do you honestly doubt that the concept of delayed >> >> evaluation has uses outside of a stream? >> >> >> >> In the most basic case it serves as a simple cache: >> >> >> >> (let ((x (delay <expr>))) >> >> ... >> >> (if ... (force x) ...) >> >> ... >> >> (if ... (force x) ...)) >> >> >> >> Lazy doesn't work here. >> > >> > *Some* `lazy's do. I missed the fact that you've crippled `lazy'. >> > (It's an odd decision that not only makes it a more limited tool, it also >> > contradicts a dynamically typed language.) >> >> I'm only aware of one definition of `lazy' - the one from srfi-45 >> and used by srfi-41. If there is an alternative definition I'd like >> to know. > > It's one that does not require to be used with a promise. > > $ racket > Welcome to Racket v5.2.1. > -> (lazy 1) > #<promise:stdin:1:0> > -> (force ^) > 1 > -> (force (lazy (lazy 2))) > 2 (I assume Racket's repl binds ^ to the last result) The standard effectively allows but does not require this extension to lazy. However, that's not really the point here. Lazy is still semantically difference from delay, because forcing a delay does not repeatedly force the result. The transformation described by Wadler for converting a strict language into a lazy one naturally uses delay and force as a pair, and results in some compositions of delay and force, in addition to isolated delays. Lazy was introduced because existing implementations leak space in the delay+force compositions. However, the distinction is still useful, gives a finer grain of control over when promises are forced, and allows for cleaner type inference. Moreover, replacing delay with a permissive lazy would break existing programs. Thus we need both in the standard, and the naming we've provided shows the relation clearly between the two while preserving consistency with R5RS and Wadler's paper. I understand we can't make everyone happy here, but I don't the the WG should spend time revisiting this naming yet again. If you'd like to file a formal comment it will stand as a more visible objection, otherwise we'll try to be clear in the non-normative rationales that there was contention on this name. -- Alex, about to hop on a plane _______________________________________________ Scheme-reports mailing list Scheme-reports@scheme-reports.org http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports