依赖于状态更新的事件处理
我想为我的项目（一个GDB / MI前端）使用玻璃钢（即反应性香蕉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在“当前”状态的假设有时是错误的。
我一直试图解决这个问题已经有一个多星期了，我只是无法弄清楚。 任何帮助深表感谢。
看起来您想在发生eStop或eCommand时发生eStateUpdate事件？
如果是这样，你可以简单地把它表示为两个事件的联合：
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事件似乎在网络内部。
关于您当前代码的行为，响应式香蕉在接收外部事件时总是执行以下操作：
reactimate s。 但可能发生的情况是，步骤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风格事件编程的（相对）简单性。
黄金法则是：
处理事件时不要调用另一个事件处理程序。
你不必遵循这个规则，而且它有时可能有用; 但如果你这样做的话事情会变得复杂。
据我所知，玻璃钢似乎不是我的问题的正确抽象。
所以我转而使用State -> IO State类型的消息。
这为我提供了所需的事件序列化以及在更新状态时执行IO的可能性。 我放松的是对事件网络的很好的描述。 但对演员来说也不算太坏。
链接地址: http://www.djcxy.com/p/62089.html