[Haskell] installing streams library

[Atila Romero]

As a haskell beginner, I saw the lack of a simple and fast standard 
library as THE major dificulty.
Yes, more than monads and lazy programming and all other stuff.
This happened because I simply could not create simple programs to 
simple task as I needed then in production work.
I work at forensic area, and have to deal with large ammounts of data 
(HD images for example).
The processing time is important to me and so is the ability to accept 
files of any size.
If an easy fast IO package become part of standard libraries, I am sure 
will make my life and of more beginners a lot easier.

Atila


Duncan Coutts wrote:
> 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
>
> _______________________________________________
> Haskell mailing list
> Haskell at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
>   


	
	
		
____________________________________________________