I am using repa
more as a "management" tool. I pass around reactive-banana
s AddHandlers
in an Array
: Array D DIM2 (AddHandler Bool)
.
Currently I am using this kludge:
mapMArray :: (Monad m, R.Source r a, R.Shape sh) => (a -> m b) -> Array r sh a -> m (Array D sh b)
mapMArray f a = do
l <- mapM f . R.toList $ a
return $ R.fromFunction sh (\i -> l !! R.toIndex sh i)
where sh = R.extent a
So I can do something like this:
makeNetworkDesc :: Frameworks t => Array D DIM2 (AddHandler Bool) -> Moment t ()
makeNetworkDesc events = do
-- inputs
aes <- mapMArray fromAddHandler events
-- outputs
_ <- mapMArray (reactimate . (print <$>)) aes
Is there a reason why this is not included in repa
?
Basically for the same reason there's nothing like parMapM
in parallel: mapM
and mapM_
(or monadic actions in general) destroy parallelism. Here's a simple example:
next :: State Int Int
next = modify (+1) >> get
Now, a hypothetical repaMapM
needs to sequence all steps in the State
monad, if one would use repaMapM (const next)
. Since this clearly defies parallelism (and can also lead to low performance), it isn't part of repa. After all, high performance and parallelism is right there in repa's description (emphasis mine):
Repa provides high performance, regular, multi-dimensional, shape polymorphic parallel arrays.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With