Moving PrimMonad from the primitive package to base

Carter Schonwald carter.schonwald at
Mon May 12 18:29:16 UTC 2014

possibly related question:

would the AMP proposal mean that i can use Functor / Applicatives on
PrimMonad for free?

currently I have to write
my own little widgets, even though both ST and IO have functor and
applicative instances

or does PrimMonad need those as constraints? (i)

(<$>) :: PrimMonad m => (a->b) -> m a -> m b
(<$>) f mv = do v <- mv ; return (f v )
{-# INLINE (<$>) #-}

(<*>) :: PrimMonad m => m (a->b) -> m a -> m b
(<*>) mf mv =  do f <- mf ; v <- mv ; return (f v)
{-# INLINE (<*>) #-}

On Mon, May 12, 2014 at 9:37 AM, Johan Tibell <johan.tibell at>wrote:

> Hi,
> 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 me.
> 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
> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list