On Fri, 10 Nov 2006, David Van Horn wrote:

> [*] You might want to delay the cons for things like referring to the current
> stream, but this is precisely what stream-delay is used for in the examples
> of the SRFI:
>
> (define from0
>  (let loop ((x 0))
>    (stream-delay
>     (stream-cons x (loop (+ x 1))))))

By the way, the document has some issues and inconsistencies that make
it confusing to the uninitiated.  This example could perfectly well also be
written as

  (define from0
   (let loop ((x 0))
     (stream-cons x (loop (+ x 1)))))

Having the stream-delay there will do no harm, but is not necessary.
Illustrating the usefulness of stream-delay by using an example where it is
not needed is not helpful at all.  The same goes for the countdown
examples in the rationale, which have an unnecessary (delay (force ---)).

The primitive (stream-delay ---) is really supposed to correspond to
the (delay (force ---)) mentioned in the rationale section that reproduces the
meaning of SML/NJ "lazy" and SRFI-45 "lazy".  The reference
implementation uses srfi-45 (lazy ---) instead of (delay (force ---)).
This is required for space safety.

In my opinion, the usage of stream-delay is never adequately explained.  See
srfi-45 for a more general explanation of the usage of the corresponding
"lazy".

Another inconsistency:  The rationale section refers to "stream-define", which
is never taken up in the specification (for good reason - stream-define is not
a good abstraction).  The rationale section should be changed to use, instead
of

   (stream-define (f ---) ----)

the correct

   (define (f ---) (stream-delay -----))

The encoding of srfi-45, which corresponds to Wadler's, gives an easy
recipe for any lazy data type (not just streams), and might clear up some
confusion if read in conjuction with srfi-40.

I would say that in its current form, the above inconsistencies subtract
signficantly from the usefullness of the srfi-40 text.

Cheers
Andre