具有状态更新的状态相关事件处理

Question

我想将 FRP（即反应香蕉 0.6.0.0）用于my project（GDB/MI 前端）。但是我在声明事件网络时遇到了麻烦。

有来自 GUI 的命令和来自 GDB 的停止事件。两者都需要处理，处理取决于系统的状态。

我目前的方法是这样的（我认为这是显示问题所需的最低复杂性）：

data Command = CommandA | CommandB
data Stopped = ReasonA  | ReasonB
data State = State {stateExec :: Exec, stateFoo :: Int}
data StateExec = Running | Stopped

create_network :: NetworkDescription t (Command -> IO ())
create_network = do
    (eCommand, fCommand) <- newEvent
    (eStopped, fStopped) <- newEvent
    (eStateUpdate, fStateUpdate) <- newEvent

    gdb <- liftIO $ gdb_init fStopped

    let
      eState = accumE initialState eStateUpdate
      bState = stepper initialState eState

    reactimate $ (handleCommand gdb fStateUpdate <$> bState) <@> eCommand
    reactimate $ (handleStopped gdb fStateUpdate <$> bState) <@> eStopped

    return fCommand

handleCommand 和 handelStopped 根据当前状态对命令做出反应并停止事件。可能的反应是调用（同步）GDB I/O 函数和触发状态更新事件。例如：

handleCommand :: GDB -> ((State -> State) -> IO ()) -> State -> Command -> IO ()
handleCommand gdb fStateUpdate state CommandA = case stateExec state of
   Running -> do
     gdb_interrupt gdb
     fStateUpdate f
 where f state' = state' {stateFoo = 23}

问题是，当f 被accumE 评估时，state' 有时与state 不同。

我不能 100% 确定为什么会发生这种情况，因为我不完全理解时间和同时性的语义以及反应香蕉中“反应”的顺序。但我猜handleStopped 触发的状态更新函数可能会在f 之前被评估，从而改变状态。

无论如何，这个事件网络会导致状态不一致，因为f 对“当前”状态的假设有时是错误的。

我已经尝试解决这个问题一个多星期了，但我就是想不通。非常感谢任何帮助。

Answer 1

据我所知，FRP 似乎不是解决我的问题的正确抽象。

所以我切换到带有State -> IO State 类型消息的演员。

这为我提供了所需的事件序列化以及在更新状态时执行 IO 的可能性。我松动的是对事件网络的精彩描述。但演员也不错。

Answer 2

您似乎想让eStateUpdate 事件在eStop 或eCommand 发生时发生？

如果是这样，您可以简单地将其表示为两个事件的并集：

let        
    eStateUpdate = union (handleCommand' <$> eCommand)
                         (handleStopped' <$> eStopped)

    handleCommand' :: Command -> (State -> State)
    handleStopped' :: Stopped -> (State -> State)

    eState = accumE initialState eStateUpdate

    etc.

请记住：事件的行为就像普通值一样，您可以将它们组合成新的值，而不是编写回调函数链。

newEvent 函数只应在您想从外部世界导入事件时使用。 eCommand 和 eStopped 就是这种情况，因为它们是由外部 GDB 触发的，但 eStateUpdate 事件似乎是网络内部的。

---

关于你当前代码的行为，reactive-banana 在接收到外部事件时总是做以下事情：

1. 计算/更新所有事件发生和行为值。
2. 按顺序运行reactimates。

但很可能会发生第 2 步再次触发网络（例如通过fStateUpdate 函数），在这种情况下，网络会计算新值并再次调用reactimates，这个函数调用。在此之后，流控制返回到仍在运行的reactimates 的第一个序列，对fStateUpdate 的第二次调用会产生奇怪的效果：网络内部的行为已经更新，但是这个调用的参数是仍然是一个旧值。像这样的：

reactimate1
reactimate2
    fStateUpdate      -- behaviors inside network get new values
        reactimate1'
        reactimate2'
reactimate3           -- may contain old values from first run!

显然，这很难解释，也很难推理，但幸运的是，如果您遵守上述指导原则，这是不必要的。

---

在某种意义上，后一部分体现了以传统风格编写事件处理程序的技巧，而前一部分体现了使用 FRP 风格的事件进行编程的（相对）简单性。

黄金法则是：

在处理事件时不要调用另一个事件处理程序。

您不必遵循此规则，它有时会很有用；但如果你这样做，事情会变得复杂。