为什么修复阵列没有mapM？

Question

背景

我使用repa更多作为"管理"工具.我绕过reactive-banana小号AddHandlers在Array:Array D DIM2 (AddHandler Bool).

目前我正在使用这个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

所以我可以这样做:

makeNetworkDesc :: Frameworks t => Array D DIM2 (AddHandler Bool) -> Moment t ()
makeNetworkDesc events = do

    -- inputs
    aes <- mapMArray fromAddHandler events

    -- outputs
    _ <- mapMArray (reactimate . (print <$>)) aes

题

有没有理由不包括在内repa？

Answer 1

基本上出于同样的原因,没有什么比parMapM并行:mapM和mapM_(或一般的monadic动作)破坏并行性.这是一个简单的例子:

next :: State Int Int
next = modify (+1) >> get

现在,假设repaMapM需要对Statemonad中的所有步骤进行排序,如果有人使用的话repaMapM (const next).由于这显然违背了并行性(并且还可能导致低性能),因此它不是修复的一部分.毕竟,高性能和并行性就在于维修的描述(强调我的):

Repa提供高性能,规则,多维,形状多态并行阵列.