[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API
From: |
Alex Shinn |
Subject: |
Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API |
Date: |
Mon, 4 Jun 2012 07:59:45 +0900 |
On Sun, Jun 3, 2012 at 8:31 PM, Moritz Heidkamp
<address@hidden> wrote:
> Alex Shinn <address@hidden> 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
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, (continued)
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, John Cowan, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Alex Shinn, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Peter Danenberg, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Alex Shinn, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Peter Danenberg, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Christian Kellermann, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Peter Danenberg, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Christian Kellermann, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Jim Ursetto, 2012/06/04
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, Moritz Heidkamp, 2012/06/03
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API,
Alex Shinn <=
- Re: [Chicken-users] ANN: lazy-seq, a port of Clojure's lazy sequence API, John Cowan, 2012/06/03