Proposal: Data.Stream

Wouter Swierstra wss at cs.nott.ac.uk
Tue Jul 10 11:30:00 EDT 2007


>>
>> I'm in favour of starting a separate stream library, and I would
>> expect it to diverge from the list library over time.
>
> I agree: this should probably be a separate library for now, until we
> see how far it grows. There's an awful lot of other things not in  
> base:
> queues, difference lists, comonads, that live outside base, and I'm  
> not
> sure there's a strong enough case yet that this should go into base.

I think you're taking Conor's quote out of context. If I understand  
it correctly, he's replying to Neil Mitchell's post; he is arguing  
for a separate library different from Data.List. I don't think he  
objects to including it in base.

Conor makes a strong case for separating lists and streams: they are  
different types, with fundamentally different properties. I don't  
claim that the proposed Stream library is the final word on the  
subject, but it is a theoretically solid and the content is  
completely uncontroversial. If nothing else, it is a starting point  
for encouraging more coinductive Haskell programming. For that  
reason, I'd argue for including it in the standard distribution.

I am not too concerned whether or not this library should go into  
base or a separate package. I'd be happy to settle for Codata.Stream.  
This is easy to separate from base and does not cause any conflicts.  
Other libraries can be added to the Codata package, as we see fit.

I would argue against calling the ByteString package Data.Stream. As  
tempting as it may be, the package is not about streams, but colists.  
There's quite some literature on the subject - see for instance Tarmo  
Uustalu's "Essence of Data Flow Programming" http://cs.ioc.ee/~tarmo/ 
papers/essence.pdf, numerous papers by Jan Rutten (http:// 
homepages.cwi.nl/~janr/papers/, for instance http://homepages.cwi.nl/ 
~janr/papers/files-of-papers/CRM.pdf), various proceedings of CALCO,  
etc. I can understand that Stream sounds quite punchy and suitably  
coinductive, but calling this library Data.Stream will confuse  
certain people. I don't want to sound at all negative: I think the  
library is nothing short of phenomenal and "by any other name would  
smell as sweet".

Best,

   Wouter


More information about the Libraries mailing list