[Haskell] installing streams library

[Duncan Coutts]

On Sat, 2006-05-20 at 00:00 -0700, Chad Scherrer wrote: 
> Thanks, Bulat. I'm looking forward to trying it out this weekend.
> 
> Is there any indication what fast IO approach might work its way into
> the standard libraries? It would be nice for idiomatic Haskell to be
> really fast by default, and I'd love to be able to show off the language
> shootout implications to coworkers.

Personally I rather like the idea of a new IO library based on lazy byte
strings or in this context it'd be more helpful to call them lazy byte
streams. I believe this could give us a system which is much more
idiomatic Haskell than an explicit buffer/IO based system and with
almost as good performance (by almost I mean at most 10%, not 50%).

The idea is that instead of pushing things like string encoding or
compression into the IO part of the system that we can leave it in the
pure part and get nicer code and still get good performance. That is,
instead of layering encoding etc into a stream that we can write things
like:

print . count . lines . decode utf8 . gunzip  =<< readFile "foo"

and have that run within 10% of the speed of C code.

Donald Stewart has been posting benchmarks to the libraries mailing list
showing that the Data.ByteString and Data.ByteString.Lazy modules can
give us near-C speed and constant memory use on huge files while still
using idiomatic Haskell code.

So instead of layering streams I want to compose functions.

> Cabal doesn't seem obvious to me. Currently my uninformed point of view
> is that the whole thing is too complicated to be worth the benefit it
> provides. Since it generally seems popular, I'm guessing that means it's
> either much simpler than it seems, or else the benefit provided is just
> enormous. Can anyone point me to a sales pitch, or provide some
> motivation for me to RTFM?

The general idea is that it provides a default build system for Haskell
libraries and programs. Otherwise people use various build systems which
are usually broken in various ways for corner cases that their authors
don't encounter.

As someone who packages Haskell progs/libs for Gentoo I can assure you
that the shift to Cabal has been a great improvement. Previously,
packages needed a great deal of manual work and often patching to
package them adequately. That's not to say that Cabal is perfect, but as
we improve it everyone benefits which was not previously the case when
everyone rolled their own build system. For example we still don't
support win32 very well but we should be able to improve that by
improving Cabal (or layering tools on top of Cabal) where as previously
you'd have to go replacing every make-based build system to get it to
work on win32.

Duncan