[plt-dev] I love Haskell (not an April Fools Joke!), feature request for 'for'

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 <eli at 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
> samth at ccs.neu.edu