rl at cse.unsw.edu.au
Thu Jul 12 03:43:39 EDT 2007
Wouter Swierstra wrote:
>>> 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.
In general, I don't think there is a "standard" definition of a stream
datatype. IIUC, you see streams as necessarily infinite but there are
other perfectly valid interpretations. Stream is simply a very broad
term which means too many different things. In particular, I don't see
why our Stream data type doesn't model streams. Anyway, IMHO to avoid
confusion we shouldn't have a standard stream type at all. And, as
Stefan O'Rear has pointed out, a non-base package probably shouldn't put
its modules under Data (unless, perhaps, it is under Data.<package>); in
any case, the package name should appear somewhere in the path.
> 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.
I have to admit that I don't really understand the distinction between
Haskell's lists and colists (or, in general, datatypes in Haskell and
codatatypes). To me, lists are inductive and colists are coinductive,
i.e., the former are the least and the latter the greatest fixed point
of the underlying functor. Thus, Haskell's list datatype actually models
colists (and algebraic datatypes in Haskell are coinductive by default).
This thread seems to implicitly assume a different interpretation of the
prefix "co" but I don't really understand what this interpretation is.
As to Data.Stream, I don't think that the ByteString library actually
includes a module with that name Our stream fusion based list library
does but that's really quite experimental and not really released, I
think. However, our streams will have to go into base at some point as
they are already used by the ByteString and NDP packages (even though
each has its own copy) and we plan on using them for Data.Array and
friends as well. The module doesn't really have to be called
More information about the Libraries