> Quoting Bulat Ziganshin <[EMAIL PROTECTED]>:
> > Haskell can't provide fast execution speed unless very low-level
> > programming style is used (which is much harder to do in Haskell than in C,
> > see one of my last messages for example) AND jhc compiler is used
I have to dispute this Bulat's characterisation here. We can solve lots
of nice problems and have high performance *right now*. Particularly
concurrency problems, and ones involving streams of bytestrings.
No need to leave the safety of GHC either, nor resort to low level evil
code.
This obsession with mutable-variable, imperative code is unhealthy, Bulat ;)
> ajb:
> The PGP format is heavily character stream-based. We know how horrible
> the performance of character streams are in Haskell. On one hand, this
> would be an excellent test case. On the other hand, performance would
> indeed suck now.
Unless you used a stream of lazy bytestrings!
As Duncan did for his pure gzip and bzip2 bindings:
compress, decompress :: ByteString -> ByteString
http://haskell.org/~duncan/zlib/docs
http://haskell.org/~duncan/bzlib/docs
With underlying stream fusion, you keep the nice high level code. And no
imperative gunk required! I see no reason a PGP tool couldn't be
implemented similarly.
-- Don
P.S. The comments on this thread makes me think that the state of the
art high perf programming in Haskell isn't widely known. Bulat-style
imperative Haskell is rarely (ever?) needed in the GHC 6.6 Haskell code
I'm writing in these days. Solving large data problems is feasible
*right now* using bytestrings.
Trying to write code using an imperative style is likely to do more harm
than good, and certainly not something to suggest to beginners on the
mailing list ;)
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
