Email list hosting service & mailing list manager

(stream-cons (1) stream-null) => stream David Van Horn (10 Nov 2006 23:38 UTC)
Re: (stream-cons (1) stream-null) => stream David Van Horn (10 Nov 2006 23:46 UTC)
Re: (stream-cons (1) stream-null) => stream AndrevanTonder (11 Nov 2006 00:41 UTC)
Re: (stream-cons (1) stream-null) => stream David Van Horn (11 Nov 2006 01:03 UTC)
Re: (stream-cons (1) stream-null) => stream AndrevanTonder (11 Nov 2006 12:32 UTC)
Re: (stream-cons (1) stream-null) => stream David Van Horn (11 Nov 2006 02:21 UTC)
Re: (stream-cons (1) stream-null) => stream AndrevanTonder (11 Nov 2006 14:19 UTC)

Re: (stream-cons (1) stream-null) => stream AndrevanTonder 11 Nov 2006 12:29 UTC

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