Question

我有一些应用程序架构，其中用户输入流到某些自动机，它在事件流的上下文中运行，并将用户引导到应用程序的不同部分。应用程序的每个部分都可以根据用户输入执行某些操作。但是，应用程序的两个部分是共享某个状态，并且在概念上是读取和写入同一个状态。需要注意的是，两个“线程”没有同时运行，其中一个“暂停”而另一个“产生”输出。描述这种状态共享计算的规范方法是什么，而不需要求助于某些全局变量？两个“线程”是否有意义保持本地状态通过某种形式的消息传递同步，即使它们不是以任何方式并发？

由于问题更具概念性，因此没有代码示例，但欢迎使用Haskell（使用任何FRP框架）或其他语言的示例答案。

Answer 1

我一直致力于解决这个问题。高级摘要是您：

A）将所有并发代码提炼为纯粹的单线程规范

B）单线程规范使用StateT来共享公共状态

整体架构的灵感来自模型 - 视图 - 控制器。你有：

控制器，是有效的输入
视图，这是有效的输出
一个模型，这是一个纯粹的流转换

模型只能与一个控制器和一个视图交互。但是，控制器和视图都是幺半群，因此您可以将多个控制器组合到一个控制器中，将多个视图组合到一个视图中。从图中可以看出，它看起来像这样：

 controller1 -                                           -> view1
              \                                         /
 controller2 ---> controllerTotal -> model -> viewTotal---> view2
              /                                         \
 controller3 -                                           -> view3

                  \______ ______/   \__ __/   \___ ___/
                         v             v          v
                     Effectful        Pure    Effectful

该模型是纯粹的单线程流转换器，它实现Arrow和ArrowChoice。原因是：

Arrow是等效并行的单线程
ArrowChoice是等同于并发的单线程

在这种情况下，我使用基于推送的pipes，它似乎有一个正确的Arrow和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变压器。原因是我们希望在基础monad中嵌入StateT以跟踪共享状态。在这种情况下，pipes适合该法案。

最后一个难题是一个复杂的现实世界的例子，它采用复杂的并发系统并将其提炼为纯粹的单线程等效系统。为此，我使用即将发布的rcpl库（“read-concurrent-print-loop”的缩写）。 rcpl库的目的是为控制台提供并发接口，使您可以在同时打印到控制台的同时读取用户的输入，但不会打印输出，从而破坏用户的输入。它的Github存储库在这里：

Link to Github Repository

我对这个库的原始实现具有普遍的并发性和消息传递，但是受到了几个我无法解决的并发错误的困扰。然后，当我想出mvc（类似FRP的框架的代号，“模型 - 视图 - 控制器”的缩写）时，我认为rcpl将是一个很好的测试用例，看看是否mvc已准备好迎接黄金时段。

我采用了rcpl的整个逻辑并将其转换为单个纯粹的管道。这就是您在this module中可以找到的内容，总逻辑完全包含在rcplCore pipe中。

这很简洁，因为现在实现是纯粹的，我可以快速检查它并验证某些属性！例如，我可能想要快速检查的一个属性是每个用户键按下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时，它仍然有几个错误，但是这些错误比我第一次迭代中的顽固并发错误更容易调试和删除。

rcpl示例使用StateT在不同组件之间共享全局状态，因此对您的问题的冗长回答是：您可以使用StateT，但前提是您改变了系统到单线程版本。幸运的是，这是可能的！

在功能反应式编程中，如何在应用程序的两个部分之间共享状态？

1 个答案: