Question

我想对my project（GDB/MI前端）使用FRP（即反应香蕉0.6.0.0）。但我在宣布事件网络方面遇到了麻烦。

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不同。

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

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

我一直试图解决这个问题超过一个星期了，我无法弄明白。非常感谢任何帮助。

Answer 1

看起来您希望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始终执行以下操作：

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

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

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

显然，这很难解释并且难以推理，但幸运的是，如果你坚持上述指导原则就没有必要。

从某种意义上说，后一部分体现了以传统风格编写事件处理程序的棘手，而前一部分体现了编程与FRP风格事件的（相对）简单性。

黄金法则是：

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

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

Answer 2

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

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

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

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

2 个答案: