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@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
____________________________________________________
_______________________________________________
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
