This page is part of the web mail archives of SRFI 40 from before July 7th, 2015. The new archives for SRFI 40 contain all messages, not just those from before July 7th, 2015.
On Monday, March 17, 2003 10:12 PM, Stephen McCracken [SMTP:samccpa@xxxxxxxxx] 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