<div dir="ltr">possibly related question: <div><br></div><div>would the AMP proposal mean that i can use Functor / Applicatives on PrimMonad for free?</div><div><br></div><div>currently I have to write</div><div>my own little widgets, even though both ST and IO have functor and applicative instances</div>

<div><br></div><div>or does PrimMonad need those as constraints? (i)</div><div><br></div><div><div>(<$>) :: PrimMonad m => (a->b) -> m a -> m b</div><div>(<$>) f mv = do v <- mv ; return (f v )</div>

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

</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 12, 2014 at 9:37 AM, Johan Tibell <span dir="ltr"><<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>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.</div>



<div><br></div><div>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</div><div><br></div><div> * provide unfoldIO, unfoldST, etc for all functions I want to expose that work over either ST or IO or</div>



<div> * depend on primitive, which is mostly unmaintained since Roman got busy with other things.</div><div><br></div><div>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.)</div>



<div><br></div><div>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.</div><div><br></div><div>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.</div>



<div><br></div><div>* 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.</div>

<span class="HOEnZb"><font color="#888888">

<div><br></div><div>-- Johan</div><div><br></div><div><br></div></font></span></div>
<br>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>