It is true that stream-length and stream-equal are both meaningful only on finite streams.  But they are different: stream-equal? requires that all the elements of the stream be materialized, while stream-length doesn't (it doesn't force the promise of the stream-car).  I'm not entirely sure that difference is sufficient to justify including stream-length but not stream-equal?, but it was good enough for me at the time I wrote the SRFI.  As I said earlier, the hardest part of writing the SRFI was deciding what to put in and what to leave out, and my default position was to leave it out unless I was sure it belonged.

Again, I have copied this note to the SRFI-41 discussion list.

On Sun, Apr 6, 2008 at 11:51 PM, Michele Simionato <xxxxxx@gmail.com> wrote:

On Apr 6, 8:36 pm, "Phil Bewig" <xxxxxx@gmail.com> wrote:
> I like comprehensions, too.  Here are my versions of list-of and fold-of:
> <snip>

There is some cut & paste error here, but don't worry ;)

> Thank you for "really really" liking it.  Have you used streams "in anger"
> in a real program?

No, actually what I really like is the documentation, since I
finally understood what streams were ;) Until a few months ago,
I was missing the memoization requirement and I had the false
impression they were just another name for iterators. Instead,
they are quite different since they can use a potentially infinite
amount of memory (and the memory requirements are not known up front).
I quite liked the "pitfalls" section too.

> There is nothing wrong with port->stream.  If you open a port, then pass it
> to port->stream, all will be fine; in fact, that's exactly what file->stream
> does.  The problem is with with-input-from-file, which is eager.

Ah, I see, the documentation spells it out loud, but still I somewhat
managed to miss the point.

> I did not include file->stream in the SRFI directly
> out of a sense of minimalism; likewise, there is no file->stream-lines.
> There is no error-handling in port->stream or file->stream because there is
> no error-handling in R5RS, and there was no R6RS implementation available at
> the time I wrote the SRFI.

Ok. BTW, reading the R6RS document I do not understand what happens
with call-with-input-file or with-input-from-file when an exception
happens: is the port automatically closed, is it closed only
in some case (which cases?), is the behavior unspecified?
This has nothing to do with streams, so everybody here is
free to answer ;)

> Stream-equal? is only defined on finite streams; it has no meaning on
> infinite streams.  And as the SRFI suggests, if you are materializing all
> the elements of a finite stream, you may as well be using a list.

Well, stream-length is only meaningful for finite streams,
still it is in the library. Also, converting two streams in lists
is fine if they are expected to be equal most of the times,
but if they are espected to be different it is inefficient.
Anyway, I do understand the point of not putting everything
in a library, so let's say it is fine as it is.

   Michele Simionato