推拉式和箭头式FRP有何根本不同？

我想在Haskell学习FRP，但是要决定要使用的库有点困难。许多似乎是无用的尝试，有些似乎已经复活（例如最近在Yampa的活动）。

根据我的阅读，似乎有两种“种类”的FRP：一侧是推拉式FRP（例如在Reactive香蕉中），而在另一侧则是箭头式FRP（在Yampa中）。似乎在Fran和FrTime时也曾经有一些“经典FRP”，但是我没有发现这些中有任何近期活动。

• 这两种（或三种）真的是玻璃钢根本不同的方法吗？

• 其中一个是过时的理论，而另一个将是“未来的东西”吗？

• 还是它们必须并行发展以解决不同的目的？

• 我是否是每个类别中最杰出的图书馆，还是有其他选择要考虑（Sodium，Netwire等）？

_{我终于看了E. Czaplicki在J. Abrahamson评论中推荐的演讲。这非常有趣，确实为我澄清了一切。我强烈推荐给任何发现此问题有趣的人。}

我前往Haskell.org进行了调查，以调查您的问题。我发现您应该阅读两篇重要的论文以进一步进行研究，并且我将从这些学术论文中为您的问题建立答案。

Conal Elliott推拉式玻璃钢

John Hughes将Monads概括为箭

1. 是的，但也没有。根据Elliot的说法，推式是数据驱动的FRP评估，而拉式则涉及所谓的“需求”驱动的评估。作者之所以推荐拉动是因为在数据输入之间，推动往往会闲置。关键是：推挽式组合并平衡了这些行为，其主要目的是将重新计算值的需求降至最低。这很简单; 通过推拉操作FRP可以增强反应能力。Arrow是使用抽象类型链接值并同时求值的另一种技术。所有这些概念都根本不同。但是请不要相信我：

   对于最小化重新评估的目标，Arrow界面的性质存在问题。输入事件和行为组合成一个输入，然后在任何组件更改时都会更改（Elliott）。

   因此，Arrow与推挽的目标相矛盾。这并不意味着您不能一次使用所有这些功能，只是那会很复杂，并且有些内容如果没有抽象Arrow类型就无法计算。

2. 我还没有找到关于哪种方法是“未来之路”的学术观点。仅注意箭头可以很好地处理同时性。如果您可以实现箭头并使用推挽式最小化计算，那将是未来的方式。

3. 是的，它们有不同的目的。就像我说的那样，它们可以一起制定，但是很难实现，即使它确实起作用，也可能抵消推挽的无功速度优势。

4. 这是主观的，但是Reactive和Yampa似乎是FRP最常引用的语言库。我想说的是Conal Elliott的Reactive根深蒂固，Yampa也成立了。其他项目，例如Netwire，是作为替代品出现的，但要取代巨头，可能还需要一段时间。

希望这可以帮助！就像我说的，阅读我指出的文章可以使您更好地理解箭头，推拉之间的语义距离。