using ghc with make
simonmarhaskell at gmail.com
Wed Apr 19 08:45:19 EDT 2006
Bulat Ziganshin wrote:
> Streams library includes AltBinary functionality and also emulation of
> two versions of NewBinary library - byte-aligned and bit-aligned one.
> as long as you search for nhc-style serialization library (i.e., with
> `get` and `put_` functions) my lib should be the best beast around. to
> be exact, it was started as fast serialization library when it become
> obvious that Joel Reymont's program is bound by serialization speed.
> and when fast serialization routines was written, i added Streams
> functionality to make this lib more useful :)
> it will be great to add all these libs i written last months to GHC
> and then Haskell' - AltBinary, Streams, unboxed references and
> refreshed implementation of Arrays library (in particular, it supports
> resizable arrays, i.e. implements one of GHC's tickets)
Believe me I've looked in detail at your streams library.
Performance-wise it is great but the design needs to be reworked IMO.
The main problem is that it doesn't have enough type structure. There
are many combinations of stream transformers that don't make sense, and
should therefore be ruled out by the type system. There are operations
that don't work on some streams. There should at the least be a type
distinction between directly accessible memory streams, byte streams,
and text streams. Additionally I would add separate classes for
seekable and buffered streams. I believe these changes would improve
performance by reducing the size of dictionaries.
There are problems with memory management: as far as I can tell, the
buffers are never freed if you just release a stream. You should be
using ForeignPtrs instead of explicitly malloc'd buffers.
Text encoding/decoding is inefficient. Not a design problem, of course,
but having good text coding support is one of the main reasons for
replacing the IO library.
I have a sketched design if you'd like to see it sometime, but I have to
extract it from the partially-written code.
More information about the Glasgow-haskell-users