1. Is this going into the code base?
2. Why is for on lazy things not practical?
-- Matthias
On Apr 2, 2009, at 9:12 PM, Sam TH wrote:
On Thu, Apr 2, 2009 at 8:48 PM, Eli Barzilay <e...@barzilay.org> wrote:
On Apr 2, Sam TH wrote:
Here's the implementation of `cycle' (which should probably be in
the
sequence library):
[...]
Below is a better implementation of `in-sequences' using a
`append-sequences' helper. It's also implementing `in-cycle', which
just uses the same `append-sequences' utility with a cyclic list of
the inputs. (And BTW, it doesn't cache the items, which looks like a
mistake to do.)
Thanks for the implementation.
Caching the items is necessary if you want to work with a sequence of
bytes from a port, for example (see `in-input-bytes-port').
But there's a problem with this -- AFAICT, there is no way for a
sequence to just return a new sequence to iterate over, which
would be
a tail-call kind of transfer to the new sequence. So the `in-lazy'
thing must create a sequence that forever wraps the input sequence.
The result is a growing chain of sequence proxies. Maybe there's a
nice way to extend the api so a sequence can stop and return a
"continuation sequence", but looking at the code that change doesn't
look easy.
When I was writing my code, I also wanted that API addition.
(let loop ([m+g+r m+g+r])
(if (and (pair? m+g+r) (not ((car m+g+r))))
(seqs->m+g+r (cddr m+g+r))
m+g+r)))
The `loop' here is never used.
--
sam th
sa...@ccs.neu.edu
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
