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 in parallel：mapM和mapM_（或一般的monadic动作） destroy 并行性。这是一个简单的例子：

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

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

Repa提供高性能，常规，多维，形状多态并行数组。

为什么修复阵列没有mapM？

背景

问题

1 个答案: