Re: [Scheme-reports] Formal Comment: what is the required behavior of 'lazy'?

[Alex Shinn <alexshinn@x>]

On Fri, Jun 29, 2012 at 10:15 AM, Eli Barzilay <eli@x> wrote:
> A few minutes ago, Alex Shinn wrote:
>> On Fri, Jun 29, 2012 at 9:32 AM, Eli Barzilay <eli@x> wrote:
>> > Yesterday, Alex Shinn wrote:
>> >> On Thu, Jun 28, 2012 at 1:39 AM, Eli Barzilay <eli@x> wrote:
>> >> > A few minutes ago, Alex Shinn wrote:
>> >> >> On Thu, Jun 28, 2012 at 1:12 AM, Eli Barzilay <eli@x> 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@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports