This page is part of the web mail archives of SRFI 41 from before July 7th, 2015. The new archives for SRFI 41 contain all messages, not just those from before July 7th, 2015.
(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" <andre@xxxxxxxxxxxxx>
To: "Phil Bewig" <pbewig@xxxxxxxxx> Cc: "David Van Horn" <dvanhorn@xxxxxxxxxxxxxxx>; <srfi-41@xxxxxxxxxxxxxxxxx> 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