[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:
(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
(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
(stream-define (f ---) ----)
(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.