7

我想为我的项目（一个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。

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

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

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

4

2 回答 2

3

看起来您想让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函数），在这种情况下，网络会计算新值并reactimate再次调用 s，作为此函数调用的一部分。在这之后，流控制返回到第一个reactimates仍在运行的序列，第二次调用fStateUpdate会产生奇怪的效果：网络内部的行为已经更新，但是这个调用的参数仍然是一个旧值。像这样的东西：

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

显然，这很难解释，也很难推理，但幸运的是，如果您遵守上述指导方针，那就没有必要了。

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

黄金法则是：

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

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

于 2012-08-03T08:38:35.193 回答
1

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

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

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

于 2012-08-06T13:00:42.130 回答