[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (stream-cons (1) stream-null) => stream

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-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

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.