Moving PrimMonad from the primitive package to base

Johan Tibell johan.tibell at
Mon May 12 13:37:39 UTC 2014


I'm pondering adding unfoldM, as generalization of fromList, to the
unordered-containers package. unfoldM could, just like fromList, be
implemented using mutation followed by freezing internally, making it much
more efficient the repeatedly calling insert when building a HashMap. A
typical use case of unfoldM would be constructing a HashMap from the
content of a file.

Here's the annoying issue: unfoldM could work in both ST and IO, but
exposing those two versions to users is a bit annoying. Either I have to
have to

 * provide unfoldIO, unfoldST, etc for all functions I want to expose that
work over either ST or IO or
 * depend on primitive, which is mostly unmaintained since Roman got busy
with other things.

Even if primitive was maintained, having to add extra library dependencies
to "bottom layer" libraries like unordered-containers is often not worth
the cost (more dependency management, risk of breakages, etc.)

Furthermore, the pixie dust that makes abstracting over ST and IO possible,
is quite tightly tied to GHC and abstracting over it there makes sense to

So I'm proposing we consider moving parts of primitive into base, in
particular the Control.Monad.Primitive module (in some form)*. This is not
a formal proposal at this point, just a request for thoughts.

* Ideally I think GHC should provide some more abstraction on top of the
primops. More or less every library that uses arrays/bytearrays (e.g. text,
unordered-container, vector) define the same trivial wrappers around
indexArray# etc.

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list