<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If you're talking about Data.Ref.Unboxed, it only seems to do what vector and primitive classify as Prim types. Not tuples and other structure-of-arrays type stuff. And all that classification is contained in primitive (Data.Primitive.Types). It covers some pointer types that Prim doesn't, but doesn't have Addrs, which Prim does.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 12, 2015 at 12:12 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yes, this is the sort of thing I was looking for. One question: if I<br>
understand it correctly, it looks like ArrayRef duplicates the logic<br>
of vector's Unbox to allow more general types without piggybacking on<br>
Vector with it (small) overhead. Am I reading this right? If so, what<br>
are the arguments against this approach?<br>
<br>
Finally, I can't seem to stop wondering if there might be some<br>
fundamentally more pleasant approach to this whole thing. The<br>
underlying basis for this suspicion comes from the fact that, as<br>
strange as it looks, `StateT v (ST s) a` actually works very well. For<br>
example, the source below produces very nice core with -O2.<br>
<br>
module STST (countUp) where<br>
import <a href="http://Control.Monad.ST" target="_blank">Control.Monad.ST</a><br>
import Control.Monad.Trans.State.Strict<br>
import Control.Monad.Trans (lift)<br>
import Control.Monad (when)<br>
import Data.Functor ((<$))<br>
import qualified Data.Vector.Unboxed.Mutable as V<br>
import Data.Vector.Unboxed.Mutable (MVector, unsafeWrite)<br>
<br>
step :: V.MVector s Int -> StateT Int (ST s) Bool<br>
step v = do<br>
i <- get<br>
if i == V.length v<br>
then return True<br>
else do<br>
lift (unsafeWrite v i i)<br>
put (i+1)<br>
return False<br>
<br>
countUp :: V.MVector s Int -> ST s ()<br>
countUp v = () <$ execStateT go 0<br>
where<br>
go = do<br>
done <- step v<br>
when (not done) go<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, Feb 11, 2015 at 10:35 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com">michael@snoyman.com</a>> wrote:<br>
> I added this to mutable-containers. It's easiest to see this by looking at<br>
> three readme on<br>
><br>
> <a href="http://www.stackage.org/package/mutable-containers" target="_blank">http://www.stackage.org/package/mutable-containers</a><br>
><br>
> I'd support something like this in primitive as well.<br>
><br>
><br>
> On Thu, Feb 12, 2015, 4:36 AM Dan Doel <<a href="mailto:dan.doel@gmail.com">dan.doel@gmail.com</a>> wrote:<br>
>><br>
>> We could add something like this to primitive. It has a generalization of<br>
>> things like STRef, under the name MutVar.<br>
>><br>
>> On Wed, Feb 11, 2015 at 7:03 PM, David Feuer <<a href="mailto:david.feuer@gmail.com">david.feuer@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> The problem they solve is perhaps not as well known as it should be:<br>
>>><br>
>>> Code that frequently modifies an `STRef Int`, for example, will<br>
>>> typically surprise the programmer by allocating a ton of memory. This<br>
>>> happens because the reference holds a *boxed* Int. Code like<br>
>>><br>
>>> modifySTRef ref (+1)<br>
>>><br>
>>> will allocate a new Int box every time. To the best of my knowledge,<br>
>>> GHC makes no attempt to figure out if this is actually necessary and<br>
>>> do something about it. The Data.Ref.Unboxed module in the ArrayRef<br>
>>> package attempts to address this, but it doesn't seem to get much<br>
>>> visibility, and its code hasn't been touched since 2009. What can we<br>
>>> do about this?<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>
>><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>
</div></div></blockquote></div><br></div>