AndrevanTonder wrote:
> In other words, I think it is legitimate to define the stream abstraction
> to be
>
>   (stream-cons exp1 exp2) = (delay (cons exp1 exp2))
>
> which is essentially how the current implementation does it, if I
> remember correctly.  Your alternative abstraction would correspond to
>
>   (stream-cons exp1 exp2) = (delay (cons (delay exp1) exp2)),

No, I don't believe the cons should be delayed.  My abstraction is simply:

    (cons (delay exp1) exp2)

Since exp2 is a stream, there really is no purpose in delaying the cons,
as far as I can tell[*].  Moreover it violates the spirit of "it is an
error if the second argument of stream-cons is not a stream"
specification since it delays the check of (stream? exp2) until either
the stream-car or stream-cdr are accessed, which may not even occur.
Such an implementation conforms only in the sense that "it is an error"
means "whatever".  With the way streams are implemented currently, you
cannot ask stream-null? or stream-pair? of a stream without forcing the
components of a pair-- again violating the specification that "no
element of the stream is evaluated until it is accessed."

David

[*] 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))))))