scala - 事件应该在外部可变吗？

Question

我在玩FRP，想知道事件“发生”的行为应如何公开处理。通过这个，我的意思是程序员应该能够在FRP上下文中执行以下操作：

event.occur(now, 5)

我从未在任何FRP论文中看到过这样的示例，这对我来说也不对。我觉得FRP框架确实应该隐藏这种类型的动作，而Event的发生应该只在幕后发生。我认为正确吗？

为了明确起见，我的方法是让事件类本身只能访问“出现”。如果需要某种外部源（例如鼠标）的抽象，则可以通过扩展Event类来构建。这样，所有与出现创建有关的逻辑都被抽象了。

Answer 1

好吧，如果FRP库提供了一种绑定外部事件的方法，例如现有的基于事件的框架-那么它必须提供与之等效的功能，否则就无法与外界互动。

但是，问题确实是：“外部”是什么意思？ FRP系统本身通常被认为是纯净的，因此从FRP系统内部执行副作用代码（如event.occur(now, 5)）的想法甚至没有意义。当然，通常，通常，提供了一种响应于FRP事件执行此类代码的工具，但这通常不被视为纯编程模型的一部分，而是被视为一种将网络作为一个整体与外界交互的工具。

因此，我认为，有两种可能的方式来解释这个问题：


是否可以从FRP系统外部触发事件？ —绝对可以，因为它是与外界交互所必需的，但这并不影响FRP本身的编程模型。
假设有某种设施可以对事件做出反应来执行副作用代码，那么是否有可能从FRP系统的“内部”触发事件？ —也是，因为允许正常的副作用代码导致事件，但在响应事件而执行的代码中禁止它，这似乎是一个非常奇怪的（也是可回避的）限制，因为该设施的目的是与外界交互。


实际上，即使您明确禁止它，也可能会导致类似＃2的情况：考虑进行设置，以便在事件switchToWindow 3触发时执行buttonClicked，例如（使用reactive-banana表示法）：

reactimate (switchToWindow 3 <$ buttonClicked)

并说我们有一个活动

newWindowFocused :: Event Int

即使已经阻止了由于事件而执行的内部代码中的触发事件，我们已经设置的响应都会引发 newWindowFocused事件。

现在，到目前为止，我所说的所有内容仅涉及“外部”事件：这些事件不是用纯FRP表示的，而是显式创建的，以表示发生在FRP系统之外的外部事件。如果您要问是否应该有一种机制可以在纯定义事件中引起特殊事件，那么我的回答是：绝对不是！这破坏了系统的含义，因为突然 fmap f (union e1 e2)并不意味着“当 f x或 e1出现值 e2时出现值 x”，而是“出现值 f x当 e1或 e2出现值为 x ...或某些外部代码随机决定触发它时”。

这样的功能不仅会使FRP系统的行为从本质上变得毫无意义[1]，而且还违反了参照透明性：如果构造两个等效于 fmap f (union e1 e2)的事件，则可以通过触发一个事件并注意到该事件来区分它们。其他不会发生。您根本无法在所有情况下都避免这种情况：设想 fmap g (union e1 e2)，其中 f计算与 g相同的函数；功能平等是不可决定的:)

当然，完全可以用一种不纯正的语言来实现FRP，但是我认为提供一种违反FRP系统本身的引用透明性的方法是一件非常糟糕的事情，因为毕竟它是一个纯模型。

如果我正确理解，那么您针对API中此缺陷（即，公开公开 occur会破坏等价事件的引用透明性等，正如我在上文中提到的那样）的解决方案将是使 occur在您的< cc>类，因此不能从外部使用它。我同意，如果您内部需要 Event，这是正确的解决方案。我还同意，如果通过对 occur进行子类化来实现外部事件，则将其公开给子类是合理的。这属于“外部胶合”，它不在FRP模型本身的范围之内，因此完全可以通过这种方式“突破规则”的能力-毕竟，这本质上是为了：打扰系统有副作用:)

因此，结论是：

不，事件不应公开此接口。

是的，您是正确的：)

1当然，您可能会说外部事件会完全停止，因为系统的整个行为最终取决于连接到外部世界的“边缘”，但这并不是真的：是的，您不能确实可以对外部事件本身承担任何责任，但是您仍然可以依靠从外部事件中构建的所有内容来遵守其构造定律。为每个事件提供“外部触发”功能意味着没有任何法律法规。