Moving PrimMonad from the primitive package to base
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
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
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@haskell.org http://www.haskell.org/mailman/listinfo/libraries
participants (2)
-
Carter Schonwald -
Johan Tibell