On Sun, Jun 3, 2012 at 8:31 PM, Moritz Heidkamp <mor...@twoticketsplease.de> wrote: > Alex Shinn <alexsh...@gmail.com> writes: >> First, the srfi-41 vs. lazy-seq comparison in the >> blog post was an apples to oranges comparison >> of a clumsy letrec vs a compact named let. If we >> rewrite the srfi-41 version in the same style as >> the lazy-seq one, then we get: >> >> (define multiples-of-three >> (let next ((n 3)) >> (stream-cons n (next (+ n 3))))) > > Ah, thanks for pointing this out -- I was really surprised that I > couldn't find a simpler way to express this with SRFI 41. I'll update > the blog article accordingly. > > >> Now, if we have a whole program or library which >> consistently uses lazy streams instead of lists, >> we can import srfi-41 renaming all the stream-* >> bindings by removing the stream- prefix (this is >> where the drop-prefix you like comes in handy). >> Then you have a normal Scheme library using >> car/cdr/cons etc. which happens to be using >> streams (and you could change the import if >> needed to toggle between the two). > > Fair enough. I was actually considering to provide a module which > exports the functions without the `lazy-' prefix, perhaps with a `*' > suffix so that it can be conviently loaded alongside regular Scheme. The > same could be done with SRFI 41, of course. What I don't quite > understand is why SRFI 41 also defines stream-let, stream-lambda etc. Do > you know of a good reason why one would want those?
For the specific case of stream-cons I believe they're useless, because stream-cons is syntax and so works well with normal let and lambda. However if you had another lazy computation not based on some constructor, say a tree, you could use stream-lambda instead of introducing a new stream-tree syntax. For a better comparison to srfi-41, you could compare using your lazy-seq against stream-lambda for some infinite tree. Internally, stream-lambda is implemented with a utility stream-lazy which is basically the same as lazy-seq. Bewig decided not to expose this utility with the following reasoning: Besides hiding lazy and making the types work out correctly, stream-lambda is obvious and easy-to-use for competent Scheme programmers, especially when augmented with the syntactic sugar of define-stream and named stream-let. The alternative of exposing stream-lazy would be less clear and harder to use. It seems for you at least the opposite was the case, and it would have been better to expose stream-lazy after all :) -- Alex _______________________________________________ Chicken-users mailing list Chicken-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/chicken-users
