FRP - 事件流和信号 - 仅使用信号会丢失什么？

Question

在经典 FRP 的最新实现中，例如反应香蕉，有事件流和信号，它们是阶跃函数（反应香蕉称它们为行为，但它们仍然是阶跃函数）。我注意到 Elm 只使用信号，并没有区分信号和事件流。此外，reactive-banana 允许从事件流到信号（已编辑：虽然它不被认为是好的做法，但可以使用 reactimate 对行为采取行动），这意味着理论上我们可以应用所有事件流通过首先将信号转换为事件流，应用然后再次转换来对信号/行为进行组合器。那么，考虑到它通常更容易使用和学习一种抽象，分离信号和事件流有什么好处？仅使用信号并将所有事件流组合器转换为对信号进行操作是否会丢失任何东西？

edit：讨论非常有趣。我自己从讨论中得出的主要结论是，相互递归定义（反馈）和输出依赖于两个输入（一个行为和一个事件源）都需要行为/事件源，但只有在一个输入时才会导致动作其中有变化 ()。

Answer 1

很遗憾，我没有想到任何参考资料，但我清楚地记得 不同的反应式作者声称这种选择只是为了提高效率。你暴露 两者都是为了让程序员选择相同想法的实现方式 更有效地解决您的问题。

我现在可能在撒谎，但我相信 Elm 将所有内容作为事件流实现 兜帽。时间之类的东西不会像事件流那么好，因为有一个 在任何时间范围内无限量的事件。我不确定 Elm 如何解决这个问题，但我 认为这是一个很好的例子，在概念上更有意义的信号 并在实施中。

Answer 2

我认为使用信号/行为抽象而不是 elm 风格的信号没有任何好处。正如您所指出的，可以在信号/行为 API 之上创建一个仅信号 API（还没有准备好使用，但请参阅 https://github.com/JohnLato/impulse/blob/dyn2/src/Reactive/Impulse/Syntax2.hs 示例）。我很确定也可以在 elm 风格的 API 之上编写信号/行为 API。这将使这两个 API 在功能上等效。

WRT 效率，使用仅信号 API，系统应该具有一种机制，其中只有具有更新值的信号才会导致重新计算（例如，如果您不移动鼠标，FRP 网络将不会重新计算指针坐标并重绘屏幕）。如果这样做了，我认为与信号和流方法相比，不会有任何效率损失。我很确定 Elm 是这样工作的。

我认为连续行为问题在这里没有任何区别（或根本没有区别）。人们所说的行为随着时间的推移是连续的，是指它们在任何时候都是被定义的（即它们是连续域上的函数）；行为本身不是连续函数。但我们实际上并没有办法随时对行为进行采样；它们只能在对应于事件的时间被采样，所以我们不能使用这个定义的全部力量！

语义上，从这些定义开始：

Event    == for some t ∈ T: [(t,a)]
Behavior == ∀ t ∈ T: t -> b

由于只能在定义事件的时间对行为进行采样，我们可以创建一个新域TX，其中TX 是定义事件的所有时间t 的集合。现在我们可以将 Behavior 定义放宽为

Behavior == ∀ t ∈ TX: t -> b

没有失去任何权力（即，这相当于我们 frp 系统范围内的原始定义）。现在我们可以枚举TX 中的所有时间来将其转换为

Behavior == ∀ t ∈ TX: [(t,b)]

除了域和量化之外，它与原始 Event 定义相同。现在我们可以将Event的域更改为TX（由TX的定义），以及Behavior的量化（从forall到for some），我们得到

Event    == for some t ∈ TX: [(t,a)]
Behavior == for some t ∈ TX: [(t,b)]

现在Event 和Behavior 在语义上是相同的，因此它们显然可以在 FRP 系统中使用相同的结构来表示。在这一步我们确实丢失了一些信息；如果我们不区分Event 和Behavior，我们就不知道Behavior 是在每次 时定义的t，但实际上我不认为这是真的很重要。 IIRC 的 elm 要求 Events 和 Behaviors 在任何时候都具有值，并且如果 Event 没有改变（即将Event 的量化更改为 @ 987654347@而不是改变Behavior的量化）。这意味着您可以将所有内容视为一个信号，并且一切正常；它只是为了让信号域恰好是系统实际使用的时间子集而实现。

我认为这个想法是在一篇关于在 Java 中实现 FRP 的论文中提出的（我现在找不到，还有其他人有链接吗？），也许来自 POPL '14？凭记忆工作，所以我的大纲没有原始证明那么严格。

没有什么可以阻止你创建一个更明确的Behavior，例如pure someFunction，这只是意味着在 FRP 系统中，您无法利用这种额外的定义性，因此更受限制的实现不会丢失任何内容。

对于时间等名义信号，请注意，使用典型的编程语言不可能实现实际的连续时间信号。由于实现必然是离散的，因此将其转换为事件流是微不足道的。

简而言之，我认为仅使用信号不会丢失任何东西。

Answer 3

（澄清：在反应香蕉中，不可能将Behavior 转换回Event。stepper 函数是单程票。有一个changes 函数，但它的type 表示它是“不纯的”并且它带有一个警告，它不保留语义。）

我相信拥有两个独立的概念会使 API 更加优雅。换句话说，它归结为 API 可用性的问题。我认为这两个概念的行为完全不同，如果你有两种不同的类型，事情就会变得更好。

例如，每种类型的直销产品是不同的。一对 Behavior 等价于一对 Behavior

(Behavior a, Behavior b) ~ Behavior (a,b)

而一对事件等价于直接和的事件：

(Event    a, Event    b) ~ Event (EitherOrBoth a b)

如果您将这两种类型合并为一种，那么这些等价将不再成立。

然而，事件和行为分离的主要原因之一是后者没有有更改或“更新”的概念。起初这似乎是一个遗漏，但它在实践中非常有用，因为它导致代码更简单。例如，考虑一个单子函数 newInput，它创建一个输入 GUI 小部件，该小部件显示参数 Behavior 中指示的文本，

input <- newInput (bText :: Behavior String)

现在的关键是显示的文本不取决于多久行为bText可能已更新（相同或不同的值） ，仅在实际值本身上。这比另一种情况更容易推理，在这种情况下，您必须考虑当两个连续事件发生具有相同值时会发生什么。您是否在用户编辑文本时重绘文本？

(当然，为了实际绘制文本，库必须与 GUI 框架交互，并跟踪行为的变化。这就是 changes 组合器的用途。但是，这可以是被视为一种优化，不能从“FRP 内”获得。）

分离的另一个主要原因是递归。大多数递归地依赖于自身的事件是不明确的。但是，如果事件和行为之间存在相互递归，则总是允许递归

e = ((+) <$> b) <@> einput
b = stepper 0 e

无需手动引入延迟，开箱即用。

Answer 4

对我来说至关重要的东西丢失了，即行为的本质，​​它是（可能是连续的）随时间不断变化的。 精确、简单、有用的语义（独立于特定的实现或执行）也经常丢失。 查看 my answer 到“功能响应式编程语言规范”，然后点击那里的链接。

无论是在时间上还是在空间上，过早的离散化都会阻碍可组合性并使语义复杂化。 考虑矢量图形（以及其他空间连续模型，如Pan's）。就像Why Functional Programming Matters 中解释的数据结构的过早限定一样。