Proposal: Data.Stream

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Proposal: Data.Stream

Wouter Swierstra
Dear all,

I just uploaded a fairly unspectacular package Data.Stream to  
Hackage. It implements quite a few operations on streams (infinite  
lists), analogous to those defined in Data.List. Sometimes it is just  
good to know a list is infinite.

* Haddock documentation: http://www.cs.nott.ac.uk/~wss/repos/Stream/ 
dist/doc/html/
* Hackage homepage: http://hackage.haskell.org/cgi-bin/hackage- 
scripts/package/Stream-0.1

I know of a few libraries that implement this package themself (Ross  
Paterson's arrow library and my IOSpec spring to mind). I think it's  
fairly uncontroversial, and would like to see it added to base (I  
realize that there are also proposals to clean up base to speed up  
the build of ghc), or at least, the standard libraries. What's the  
right way to accomplish this? Send a darcs patch to Ian? Submit a  
trac ticket?

Thanks,

   Wouter
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Stefan O'Rear
On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
> Dear all,
>
> I just uploaded a fairly unspectacular package Data.Stream to Hackage. It
> implements quite a few operations on streams (infinite lists), analogous to
> those defined in Data.List. Sometimes it is just good to know a list is
> infinite.

Unfortunately, there is a bit of a name collision here; Coutts, Stewart,
and Leshchinskiy are pushing for a completely unrelated Data.Stream to
be added to base.  (Theirs is a package of operations on lists defined
by generalized unfold operators.)

> * Haddock documentation:
> http://www.cs.nott.ac.uk/~wss/repos/Stream/dist/doc/html/
> * Hackage homepage:
> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1
>
> I know of a few libraries that implement this package themself (Ross
> Paterson's arrow library and my IOSpec spring to mind). I think it's fairly
> uncontroversial, and would like to see it added to base (I realize that
> there are also proposals to clean up base to speed up the build of ghc), or
> at least, the standard libraries. What's the right way to accomplish this?
> Send a darcs patch to Ian? Submit a trac ticket?
http://haskell.org/haskellwiki/Library_submissions

(and people wonder why base is so stagnant?)

Stefan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Heinrich Apfelmus
Stefan O'Rear wrote:
> On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
>>
>> I just uploaded a fairly unspectacular package Data.Stream to Hackage. It
>> implements quite a few operations on streams (infinite lists)
>
> Unfortunately, there is a bit of a name collision here; Coutts, Stewart,
> and Leshchinskiy are pushing for a completely unrelated Data.Stream to
> be added to base.  (Theirs is a package of operations on lists defined
> by generalized unfold operators.)

How about Data.Colist for infinite lists :)

Regards,
apfelmus

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Wouter Swierstra

 > snip

Thanks for the link, Stefan. That's exactly what I was looking for.  
I've created a ticket and will add the corresponding darcs patch  
shortly.

On 9 Jul 2007, at 19:46, apfelmus wrote:
>> and Leshchinskiy are pushing for a completely unrelated  
>> Data.Stream to
>> be added to base.  (Theirs is a package of operations on lists  
>> defined
>> by generalized unfold operators.)
>
> How about Data.Colist for infinite lists :)

The problem with calling it Colist, is that a Colist can still have a  
base case. I consider Colists the same as "lazy lists", that Haskell  
programmers are familiar with. Streams on the other hand, do *not*  
have a base case and are necessarily infinite.

I realize there's a bit of a naming conflict with Don, Duncan, and  
Roman's "Data.List.Stream". Clearly, their library should have been  
called "Data.List.ImpredicativeChurchEncodingOfNuX.OnePlusATimesX" :)

On a more serious note, this proposal has no chance if we can't agree  
no some name. I could almost settle for "Data.Infinite.Stream" or  
maybe even "Data.Infinite.List". I'd welcome any other suggestions.

   Wouter


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Stefan O'Rear
On Mon, Jul 09, 2007 at 08:15:07PM +0200, Wouter Swierstra wrote:
[snip]
> I realize there's a bit of a naming conflict with Don, Duncan, and Roman's
> "Data.List.Stream". Clearly, their library should have been called
> "Data.List.ImpredicativeChurchEncodingOfNuX.OnePlusATimesX" :)

No.

There is a bit of a naming conflict with Don, Duncan, and Roman's
"Data.Stream".

This would be a lot easier if we had a hierarchal module namespace de
facto.

Stefan


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Neil Mitchell
Hi Wouter,

> I just uploaded a fairly unspectacular package Data.Stream to
> Hackage. It implements quite a few operations on streams (infinite
> lists), analogous to those defined in Data.List. Sometimes it is just
> good to know a list is infinite.

What is the advantage of knowing that a list is infinite? Are these
versions just identical to the Data.List versions, but you know you
won't encounter [] ? If so, I'm not sure there is a pressing need for
this. I would have thought a much more common problem is telling the
difference between an empty list and a non-empty list, rather than an
infinite list and another type of list.

I'm not saying that its not useful, I'm just not sure it deserves to
be in the base libraries. We could add a multitude of different data
types, each of which is "a list by some other name", but we'd probably
end up confusing users more than helping them.

As a related point, if you do use infinite lists, and are worried that
your operations might cause a pattern-match error, Catch will detect
this and prove it for you:

http://www-users.cs.york.ac.uk/~ndm/catch/

Thanks

Neil
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Conor McBride
In reply to this post by Heinrich Apfelmus
Hi

On 9 Jul 2007, at 18:46, apfelmus wrote:

> Stefan O'Rear wrote:
>> On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
>>>
>>> I just uploaded a fairly unspectacular package Data.Stream to  
>>> Hackage. It
>>> implements quite a few operations on streams (infinite lists)
>>
>> Unfortunately, there is a bit of a name collision here; Coutts,  
>> Stewart,
>> and Leshchinskiy are pushing for a completely unrelated  
>> Data.Stream to
>> be added to base.  (Theirs is a package of operations on lists  
>> defined
>> by generalized unfold operators.)
>
> How about Data.Colist for infinite lists :)

It's such a precarious business, this. But, by way of documentation,

data   List   x = Nil | Cons x (List x)
codata CoList x = Nil | Cons x (CoList x)
codata Stream x =       Cons x (Stream x)

Which of these things are what, if you're a scrupulous (co)programmer?

             | List       | CoList     | Stream
------------+------------+------------+------------
Functor     | Yes        | Yes        | Yes
------------+------------+------------+------------
Applicative | Yes-nondet | Yes-nondet |
             |            | Yes-zipmin | Yes-zip
------------+------------+------------+------------
Monad       | Yes-nondet | No         | Yes-zip
------------+------------+------------+------------
CoMonad     | No         | No         | Yes
------------+------------+------------+------------
Monoid      | Yes        | Yes        | No

By Yes-nondet, I mean monadic/applicative with respect to the
return/concatMap structure. By Yes-zipmin, I mean applicative
via a truncating zip operation. The stream monad is not the same as
the list monad: the stream join takes the diagonal of an infinite
matrix.

It's interesting to add columns for *nonempty* lists and colists, but  
I'll
leave that for another time. Similarly, I can think of a few more  
rows...

Anyhow, the point is this. The fact that Haskell's [] is big enough to
represent all of these things does not mean that [] is all we need in
the library. If a type is just a bucket to chuck data into, we should  
base
the library on leaf-labelled binary trees, with a special notation for
right-nested spines.

But we use types to indicate computational structure and to guide
the specialisation of overloaded operations (eg traverse) which exploit
that structure. Types tell us what the programs are: lists and streams
have different computational structure, hence different (co)programs.

I'm in favour of starting a separate stream library, and I would
expect it to diverge from the list library over time.

All the best

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Wouter Swierstra
In reply to this post by Neil Mitchell
> What is the advantage of knowing that a list is infinite?

There is plenty of overlap with the *functions* defined in Data.List,  
but the *data types* are really different. Conor emphasizes this  
point by tabulating the different structure Streams, Lists and  
CoLists carry.

This distinction makes perfect sense if you distinguish between data  
and codata. Languages such as Coq have separate types for (inductive)  
lists and (coinductive) streams. See the Coq standard libraries for  
instance:

http://coq.inria.fr/V8.1/stdlib/Coq.Lists.List.html
http://coq.inria.fr/V8.1/stdlib/Coq.Lists.Streams.html

I've encountered the need for streams, as opposed to lists, on  
several occassions. I know that Ross Paterson's arrow library defines  
a Data.Stream as well (used in Control.Arrows.Internal). I'm sure  
these aren't the only places where you really want to use streams  
instead of lists.

As far as name clashes are concerned, Andres Loeh suggested  
Codata.Stream. I realize this requires the creation of a new category  
of libraries, but its the best suggestion I've heard so far.

   Wouter
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Stefan O'Rear
On Mon, Jul 09, 2007 at 10:51:35PM +0200, Wouter Swierstra wrote:
> As far as name clashes are concerned, Andres Loeh suggested Codata.Stream.
> I realize this requires the creation of a new category of libraries, but
> its the best suggestion I've heard so far.

Currenly, Haskell package main module names almost invariably take the
form Data.* for some value of *.  This utterly defeats the point of a
hierarchy!  I'd like to see *lots* more top level categories, on the
order of sqrt(packages in hackage).

Stefan

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Donald Bruce Stewart
In reply to this post by Stefan O'Rear
stefanor:

> On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
> > Dear all,
> >
> > I just uploaded a fairly unspectacular package Data.Stream to Hackage. It
> > implements quite a few operations on streams (infinite lists), analogous to
> > those defined in Data.List. Sometimes it is just good to know a list is
> > infinite.
>
> Unfortunately, there is a bit of a name collision here; Coutts, Stewart,
> and Leshchinskiy are pushing for a completely unrelated Data.Stream to
> be added to base.  (Theirs is a package of operations on lists defined
> by generalized unfold operators.)
>

He's talking about this module, btw,

    http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Conor McBride
Hi folks

On 10 Jul 2007, at 00:05, Donald Bruce Stewart wrote:

> stefanor:
>> On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
>>> Dear all,
>>>
>>> I just uploaded a fairly unspectacular package Data.Stream to  
>>> Hackage. It
>>> implements quite a few operations on streams (infinite lists),  
>>> analogous to
>>> those defined in Data.List. Sometimes it is just good to know a  
>>> list is
>>> infinite.
>>
>> Unfortunately, there is a bit of a name collision here; Coutts,  
>> Stewart,
>> and Leshchinskiy are pushing for a completely unrelated  
>> Data.Stream to
>> be added to base.  (Theirs is a package of operations on lists  
>> defined
>> by generalized unfold operators.)
>>
>
> He's talking about this module, btw,
>
>     http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs

This looks like lovely stuff, but I'm not sure Stream is the right  
name. This
is a very cunning CoList package, by the looks of things, exploiting the
key computational structure of codata, namely being built from  
coalgebras.

But maybe I should shut up, as I always lose fights about names.

Cheers

Conor

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Donald Bruce Stewart
In reply to this post by Conor McBride
ctm:

> Hi
>
> On 9 Jul 2007, at 18:46, apfelmus wrote:
>
> >Stefan O'Rear wrote:
> >>On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
> >>>
> >>>I just uploaded a fairly unspectacular package Data.Stream to  
> >>>Hackage. It
> >>>implements quite a few operations on streams (infinite lists)
> >>
> >>Unfortunately, there is a bit of a name collision here; Coutts,  
> >>Stewart,
> >>and Leshchinskiy are pushing for a completely unrelated  
> >>Data.Stream to
> >>be added to base.  (Theirs is a package of operations on lists  
> >>defined
> >>by generalized unfold operators.)
> >
> >How about Data.Colist for infinite lists :)
>
> It's such a precarious business, this. But, by way of documentation,
>
> data   List   x = Nil | Cons x (List x)
> codata CoList x = Nil | Cons x (CoList x)
> codata Stream x =       Cons x (Stream x)
>
> Which of these things are what, if you're a scrupulous (co)programmer?
>
>             | List       | CoList     | Stream
> ------------+------------+------------+------------
> Functor     | Yes        | Yes        | Yes
> ------------+------------+------------+------------
> Applicative | Yes-nondet | Yes-nondet |
>             |            | Yes-zipmin | Yes-zip
> ------------+------------+------------+------------
> Monad       | Yes-nondet | No         | Yes-zip
> ------------+------------+------------+------------
> CoMonad     | No         | No         | Yes
> ------------+------------+------------+------------
> Monoid      | Yes        | Yes        | No
>
> By Yes-nondet, I mean monadic/applicative with respect to the
> return/concatMap structure. By Yes-zipmin, I mean applicative
> via a truncating zip operation. The stream monad is not the same as
> the list monad: the stream join takes the diagonal of an infinite
> matrix.
>
> It's interesting to add columns for *nonempty* lists and colists, but  
> I'll
> leave that for another time. Similarly, I can think of a few more  
> rows...
>
> Anyhow, the point is this. The fact that Haskell's [] is big enough to
> represent all of these things does not mean that [] is all we need in
> the library. If a type is just a bucket to chuck data into, we should  
> base
> the library on leaf-labelled binary trees, with a special notation for
> right-nested spines.
>
> But we use types to indicate computational structure and to guide
> the specialisation of overloaded operations (eg traverse) which exploit
> that structure. Types tell us what the programs are: lists and streams
> have different computational structure, hence different (co)programs.
>
> 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.

A standalone package would be my preference.

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Wouter Swierstra
>>
>> 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
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Ashley Yakeley
In reply to this post by Stefan O'Rear
Stefan O'Rear wrote:

> Unfortunately, there is a bit of a name collision here; Coutts, Stewart,
> and Leshchinskiy are pushing for a completely unrelated Data.Stream to
> be added to base.  (Theirs is a package of operations on lists defined
> by generalized unfold operators.)

And then there's monadic streams, such as sources and sinks of Word8s as
might be used by file and network streams.

--
Ashley Yakeley

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Roman Leshchinskiy
In reply to this post by Wouter Swierstra
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
Data.Stream, though.

Roman


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Stefan Holdermans
Roman,

> 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.

In Haskell, coinductive types and inductive types coincide. So,  
Haskell's [] models both lists and colists.

Cheers,

   Stefan
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Roman Leshchinskiy
Stefan Holdermans wrote:
>
> In Haskell, coinductive types and inductive types coincide. So,
> Haskell's [] models both lists and colists.

In what sense do they coincide? Inductive lists are a subset of
coinductive ones but that's not Haskell-specific. In fact, I can
perfectly well define inductive lists in Haskell:

data IList a = Nil | Cons a !(IList a)

Roman


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Ian Lynagh
In reply to this post by Wouter Swierstra
On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
>
> * Hackage homepage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1
>
> fairly uncontroversial, and would like to see it added to base (I  
> realize that there are also proposals to clean up base to speed up  
> the build of ghc),

Yes indeed; I don't see any reason for adding this to the base library
while we're trying to make base smaller.

> or at least, the standard libraries.

I'm not sure what you mean by "the standard libraries". It wouldn't be
needed to build GHC, so it wouldn't be a GHC "core lib".

Other than that, if it's in hackage then it's as standard as any other
library!

A "stream" (or "colist" or whatever) package seems reasonable to me.


(The http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs
module also looks too specific to use such a generic name, in my
opinion).


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Ian Lynagh
In reply to this post by Wouter Swierstra
On Mon, Jul 09, 2007 at 08:15:07PM +0200, Wouter Swierstra wrote:
>
> maybe even "Data.Infinite.List".

Data.List.Infinite would make more sense than this, I think (but I don't
necessarily prefer it to Data.Stream or other suggestions that have been
made).


Thanks
Ian

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: Proposal: Data.Stream

Donald Bruce Stewart
In reply to this post by Ian Lynagh
igloo:

> On Mon, Jul 09, 2007 at 03:38:56PM +0200, Wouter Swierstra wrote:
> >
> > * Hackage homepage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Stream-0.1
> >
> > fairly uncontroversial, and would like to see it added to base (I  
> > realize that there are also proposals to clean up base to speed up  
> > the build of ghc),
>
> Yes indeed; I don't see any reason for adding this to the base library
> while we're trying to make base smaller.
>
> > or at least, the standard libraries.
>
> I'm not sure what you mean by "the standard libraries". It wouldn't be
> needed to build GHC, so it wouldn't be a GHC "core lib".
>
> Other than that, if it's in hackage then it's as standard as any other
> library!
>
> A "stream" (or "colist" or whatever) package seems reasonable to me.
>
>
> (The http://www.cse.unsw.edu.au/~dons/code/streams/list/Data/Stream.hs
> module also looks too specific to use such a generic name, in my
> opinion).
>

Yes, I agree. Probably if it will be the base for fusion in ndp arrays,
bytestrings and lists, we can find a tag to put between Data.* and
*.Stream.

-- Don
_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
12