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

[AndrevanTonder <andre@xxxxxxxxxxxxx>]

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

> AndrevanTonder wrote:

> > On Fri, 10 Nov 2006, David Van Horn wrote:
> >
> > > David Van Horn wrote:
> > >
> > >    (stream-cdr (stream-cons (1) stream-null))
> > >
> > > Which should evaluate to a stream ...
> >
> > I do not think this statement is necessarily correct.  I believe it is 
> > legitimate for this to give the error it currently does.
>
> My interpretation is based on the following:
>
>  "no element of the stream is evaluated until it is accessed."
>
> Nowhere is the car element accessed, so it should not be evaluated.

I thought the intended semantics was summarized in the first example of the 
rationale section, which compares even and odd streams.  This is the semantics
used by Wadler et al. also, and it is reasonably well-understood:

  ;;; FIGURE 2 -- EVEN

  (define nil2 (delay '()))

  (define (nil2? strm)
    (null? (force strm)))

  (define-syntax cons2
    (syntax-rules ()
      ((cons2 obj strm)
       (delay (cons obj strm)))))

  (define (car2 strm)
    (car (force strm)))

  (define (cdr2 strm)
    (cdr (force strm)))

> No, I don't believe the cons should be delayed.  My abstraction is simply:
>
>   (cons (delay exp1) exp2)

This is a different abstraction, though, from the above "even streams", 
and so I don't think this was the intent of the author.

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

If you are implementing Wadler's "even streams", which I believe was the 
intent, you have no alternative but to delay the check until access.

But I am not sure I understand why that is bad.  Your alternative 
suggestion also delays an error, though in the first argument, until access:

  (stream-cons (1) stream-null)

There may not be anything fundamentally wrong with your abstraction, but it is 
a different semantics, and I think any change to semantics at this 
post-finalization stage might be difficult to justify.

Regards
Andre