(stream? (stream-car (stream 1 2 3))) ==> #f in all versions of Phils srfi 41.
(stream? (stream-car (stream (stream 1 2 3) 4 5))) ==> #t in all versions of
Phils srfi 41.

(stream? (stream-car s)) ==> #t if and only if s is a stream-pair whose first
element forces to a stream.
1: (stream-car s) is evaluated, for stream? is a procedure.
2: s is evaluated, because stream-car is a procedure.
3: stream-car checks the value of s to be a stream-pair.
4: stream-car forces the promise of the car.
5: stream? does not force its argument.

The representation of the promise of the car is irrelevant, I think (when
ignoring efficiency)
Jos

((((lambda(x)((((((x x)x)x)x)x)x))
   (lambda(x)(lambda(y)(x(x y)))))
  (lambda(x)(write x)x))
 'greeting)
----- Original Message -----
>From: "AndrevanTonder" <xxxxxx@het.brown.edu>
To: "Phil Bewig" <xxxxxx@gmail.com>
Cc: "David Van Horn" <xxxxxx@cs.brandeis.edu>; <srfi-41@srfi.schemers.org>
Sent: Thursday, November 15, 2007 2:19 PM
Subject: Re: Should the car be a stream?

> On Wed, 14 Nov 2007, Phil Bewig wrote:
>
>> I think I am saying (eq? stream-type promise-type) is #t and Andre is saying
>> (eqv? stream-type promise-type) is #f.  Both statements are correct.  Since
>> both stream-type and promise-type are abstract, I can mix them up inside
>> (streams primitive) without consequence, except that it causes some
>> confusion.  I guess it is more precise to say that the type of the
>> stream-car is a promise, not a stream, except that in the implementation
>> they are the same thing.
>
> I do not agree that it is without consequence.  From
>
>   (stream? (stream-car s)) ==> #t
>
> one would conclude that the car element is always either infinite or a finite
> stream ending in stream-null, which is not true.
>
> Andre
>
>