我一直在研究这个问题的解决方案。概括地说，您：
A）将所有并发代码提炼为纯粹的单线程规范
B) 单线程规范使用StateT共享共同状态
整体架构的灵感来自模型-视图-控制器。你有：
- 控制器，是有效的输入
- 视图，是有效的输出
- 模型，纯粹的流转换
该模型只能与一个控制器和一个视图交互。但是，控制器和视图都是幺半群，因此您可以将多个控制器组合成一个控制器，将多个视图组合成一个视图。从图表上看，它看起来像这样：
controller1 - -> view1
\ /
controller2 ---> controllerTotal -> model -> viewTotal---> view2
/ \
controller3 - -> view3
\______ ______/ \__ __/ \___ ___/
v v v
Effectful Pure Effectful
该模型是一个纯粹的单线程流转换器，它实现Arrow and ArrowChoice。原因是这样的：
-
Arrow单线程相当于并行
-
ArrowChoice单线程相当于并发
在本例中，我使用基于推送的pipes，这似乎有一个正确的Arrow and ArrowChoice例如，虽然我仍在努力验证法律，所以在我完成他们的证明之前，这个解决方案仍然是实验性的。对于那些好奇的人来说，相关的类型和实例是：
newtype Edge m r a b = Edge { unEdge :: a -> Pipe a b m r }
instance (Monad m) => Category (Edge m r) where
id = Edge push
(Edge p2) . (Edge p1) = Edge (p1 >~> p2)
instance (Monad m) => Arrow (Edge m r) where
arr f = Edge (push />/ respond . f)
first (Edge p) = Edge $ \(b, d) ->
evalStateP d $ (up \>\ unsafeHoist lift . p />/ dn) b
where
up () = do
(b, d) <- request ()
lift $ put d
return b
dn c = do
d <- lift get
respond (c, d)
instance (Monad m) => ArrowChoice (Edge m r) where
left (Edge k) = Edge (bef >=> (up \>\ (k />/ dn)))
where
bef x = case x of
Left b -> return b
Right d -> do
_ <- respond (Right d)
x2 <- request ()
bef x2
up () = do
x <- request ()
bef x
dn c = respond (Left c)
该模型还需要是一个 monad 转换器。原因是我们想要嵌入StateT在基本 monad 中跟踪共享状态。在这种情况下，pipes符合要求。
难题的最后一部分是一个复杂的现实世界示例，该示例采用复杂的并发系统并将其提炼为纯单线程等效系统。为此，我使用即将推出的rcpl库（“读取并发打印循环”的缩写）。目的rcpl库的目的是为控制台提供一个并发接口，使您可以在并发打印到控制台的同时读取用户的输入，但打印的输出不会破坏用户的输入。它的 Github 存储库在这里：
链接到 Github 存储库 https://github.com/Gabriel439/Haskell-RCPL-Library/tree/ac117d32eac5009504b700f9f29e3fada111e91c
我最初对该库的实现具有普遍的并发性和消息传递，但受到几个我无法解决的并发错误的困扰。然后当我想出mvc（我的类似 FRP 的框架的代号，“模型-视图-控制器”的缩写），我认为rcpl将是一个很好的测试用例，看看是否mvc已经准备好迎接黄金时段了。
我把整个逻辑都掌握了rcpl并将其变成一个单一的、纯净的管道。这就是你会发现的该模块 https://github.com/Gabriel439/Haskell-RCPL-Library/blob/ac117d32eac5009504b700f9f29e3fada111e91c/RCPL.hs，并且总逻辑完全包含在rcplCore pipe https://github.com/Gabriel439/Haskell-RCPL-Library/blob/ac117d32eac5009504b700f9f29e3fada111e91c/RCPL.hs#L237.
这很巧妙，因为现在实现是纯粹的，我可以快速检查它并验证某些属性！例如，我可能想要快速检查的一个属性是，每次用户按下键盘上的按键时，恰好有一个终端命令。x键，我将这样指定：
>>> quickCheck $ \n -> length ((`evalState` initialStatus) $ P.toListM $ each (replicate n (Key 'x')) >-> runEdge (rcplCore t)) == n || n < 0
n是我按下的次数x钥匙。运行该测试会产生以下输出：
*** Failed! Falsifiable (after 17 tests and 6 shrinks):
78
QuickCheck发现我的财产是假的！此外，由于代码是引用透明的，QuickCheck 可以将反例缩小到最小复制违规。按下 78 键后，终端驱动程序会发出换行符，因为控制台有 80 个字符宽，提示符占用了两个字符 ("> "在这种情况下）。如果并发性和IO感染了我的整个系统。
拥有纯粹的设置还有另一个原因：一切都是完全可重现的！如果我存储所有传入事件的日志，那么每当出现错误时，我都可以重播这些事件，并完美地再现测试用例，并将其添加到我的测试套件中。
然而，纯粹性最重要的好处实际上是能够更轻松地推理代码，无论是非正式的还是正式的。当您从等式中删除 Haskell 的调度程序时，您可以静态地证明有关代码的事情，而当您必须依赖于具有非正式指定语义的并发运行时时，您无法证明这些事情。实际上，即使对于非正式推理，这也被证明非常有用，因为当我将代码转换为使用mvc它仍然有几个错误，但这些错误比我第一次迭代中的顽固并发错误更容易调试和删除。
The rcpl示例用途StateT在不同组件之间共享全局状态，因此您问题的冗长答案是：您可以使用StateT，但前提是您将系统转换为单线程版本。幸运的是这是可能的！
