On Monday, March 17, 2003 10:12 PM, Stephen McCracken [SMTP:xxxxxx@yahoo.com] wrote:
> Although I recognize that the reference implementation
> needn't be optimized, I couldn't help but make a few
> suggestions:
>
> As stream->list is used in many places, it could be
> imperative, or at least use built-in R5RS reverse.
>
> Functions that expand their entire argument (e.g.
> stream-reverse, stream-scan-right) could probably save
> space by using real lists as intermediate data
> structures, rather than building nested stream-conses.
>  They would return their results via list->stream.
>
> The functions vector->stream, stream->vector,
> string->stream, and stream->string should not use
> lists as intermediate values, because a list may take
> up much more memory than its corresponding vector or
> string.  Converting vectors and strings directly to
> streams is trivial, while stream->string and
> stream->vector could use a simple buffer/concatenate
> strategy with just R5RS primitives.
>

Good suggestions all, and I may incorporate some of them
in the revised reference implementation that I am now
preparing, as time permits.

However, in the text of the SRFI I emphatically proclaimed
that efficiency was not a concern, and I still maintain that
position (the only efficiency note that I specified was that
stream-sort must be O(n log n), not O(n^2)).  I strongly
believe that the profile of any reference implementation
will be dominated by the time needed to create, evaluate
and garbage collect all the closures implied by the various
"delay" statements that are hidden in the low-level
implementation, and any native implementation will have
to use knowledge internal to the interpreter/compiler to
gain reasonable efficiency.

Phil