什么是（函数式）反应式编程？

Question

我读过关于反应式编程的维基百科文章。 我还阅读了关于函数反应式编程的小文章。 描述很抽象。

1. 函数式反应式编程（FRP）在实践中意味着什么？
2. 反应式编程（相对于非反应式编程？）由什么组成？

我的背景是命令式/OO 语言，因此与此范例相关的解释将不胜感激。

Answer 1

如果您想了解 FRP，可以从 1998 年的旧 Fran 教程 开始，其中有动画插图。 对于论文，请从功能反应动画开始，然后跟进以下链接我主页上的出版物链接和 FRP 链接.org/haskellwiki/Haskell" rel="noreferrer">Haskell 维基。

就我个人而言，我喜欢在讨论如何实施 FRP 之前先思考一下 FRP 的含义。
（没有规范的代码是没有问题的答案，因此“甚至没有错误”。）
因此，我不会像 Thomas K 在另一个答案（图、节点、边、触发、执行等）中那样用表示/实现术语来描述 FRP。
有许多可能的实现方式，但没有一个实现说明 FRP 是什么。

我确实对 Laurence G 的简单描述产生了共鸣，即 FRP 是关于“代表‘随时间变化’的值的数据类型”。
传统的命令式编程仅通过状态和突变间接捕获这些动态值。
完整的历史（过去、现在、未来）没有一流的表现。
此外，由于命令范式在时间上是离散的，因此只能（间接）捕获离散演化的值。
相比之下，FRP 可以直接捕获这些不断变化的值，并且对于持续不断变化的值毫无困难。

FRP 的不同寻常之处还在于它是并发的，并且不会与理论和实际相冲突。 困扰命令式并发的务实鼠巢。
从语义上讲，FRP 的并发性是细粒度、确定和连续。
（我说的是含义，而不是实现。实现可能涉及也可能不涉及并发或并行性。）
语义确定性对于严格推理和非正式推理都非常重要。
虽然并发性给命令式编程增加了巨大的复杂性（由于非确定性交错），但在 FRP 中却毫不费力。

那么，什么是玻璃钢？
你本来可以自己发明的。
从这些想法开始：

• 动态/不断变化的价值观（即“随着时间的推移”的价值观）本身就是一流的价值观。 您可以定义它们并组合它们，将它们传递到 & 超出功能。 我将这些东西称为“行为”。

• 行为是由一些原语构建的，例如恒定（静态）行为和时间（如时钟），然后进行顺序和并行组合。 n 行为通过应用 n 元函数（在静态值上）“逐点”组合，即随着时间的推移连续进行。

• 为了解释离散现象，有另一种类型（系列）的“事件”，每个事件都有一个发生流（有限或无限）。 每个事件都有一个关联的时间和值。

• 要想出可以构建所有行为和事件的组合词汇，请尝试一些示例。 继续解构为更通用/简单的片段。

• 为了让您知道自己有坚实的基础，请使用指称语义技术为整个模型提供组合基础，这意味着 (a) 每种类型都有一个相应的简单 & 精确的数学类型的“含义”，并且（b）每个原语和运算符都有一个简单的 & 。 作为成分含义的函数的精确含义。
  永远、永远不要将实施考虑因素混入您的探索过程中。 如果此描述对您来说是胡言乱语，请参阅 (a)具有类型类态射的指称设计, (b) 推拉函数反应式编程 （忽略实现位），以及 (c) 指称语义 Haskell wikibooks 页面。 请注意，指称语义有两个部分，分别来自其两位创始人 Christopher Strachey 和 Dana Scott：简单的和简单的。 更有用的 Strachey 部分和更难且不太有用的（对于软件设计）Scott 部分。

如果您坚持这些原则，我希望您或多或少会得到一些符合 FRP 精神的东西。

我从哪里得到这些原则？ 在软件设计中，我总是问同样的问题：“这意味着什么？”。
指称语义学为我这个问题提供了一个精确的框架，并且符合我的审美（与操作或公理语义不同，这两者都让我不满意）。
所以我问自己什么是行为？
我很快意识到命令式计算的时间离散性质是对特定类型机器的适应，而不是行为本身的自然描述。
我能想到的最简单的行为精确描述就是“（连续）时间的函数”，所以这就是我的模型。
令人高兴的是，这个模型可以轻松优雅地处理连续的、确定性的并发。

正确有效地实施这个模型是一个相当大的挑战，但那是另一回事了。

Answer 2

在纯函数式编程中，没有副作用。 对于许多类型的软件（例如，任何与用户交互的软件），副作用在某种程度上是必要的。

在保留函数式风格的同时获得类似副作用的行为的一种方法是使用函数式反应式编程。 这是函数式编程和反应式编程的结合。 （您链接到的维基百科文章是关于后者的。）

反应式编程背后的基本思想是，某些数据类型代表“随着时间的推移”的值。 涉及这些随时间变化的值的计算本身将具有随时间变化的值。

例如，您可以将鼠标坐标表示为一对随时间变化的整数值。 假设我们有类似的东西（这是伪代码）：

x = <mouse-x>;
y = <mouse-y>;

在任何时刻，x 和 y 都会有鼠标的坐标。 与非反应式编程不同，我们只需要进行一次分配，x 和 y 变量将自动保持“最新”。 这就是为什么反应式编程和函数式编程能够很好地协同工作：反应式编程消除了对变量进行变异的需要，同时仍然允许您完成许多可以通过变量变异完成的事情。

如果我们基于此进行一些计算，结果值也将是随时间变化的值。 例如：

minX = x - 16;
minY = y - 16;
maxX = x + 16;
maxY = y + 16;

在此示例中，minX 将始终比鼠标指针的 x 坐标小 16。 使用反应感知库，您可以这样说：

rectangle(minX, minY, maxX, maxY)

并且将在鼠标指针周围绘制一个 32x32 框，并跟踪它移动的位置。

这是一篇非常好的关于函数式响应式编程的论文< /a>.

Answer 3

获得第一直觉的一个简单方法是想象您的程序是一个电子表格，所有变量都是单元格。 如果电子表格中的任何单元格发生更改，则引用该单元格的任何单元格也会发生更改。 玻璃钢也是如此。 现在想象一些单元格自己改变（或者更确切地说，从外部世界获取）：在 GUI 情况下，鼠标的位置就是一个很好的例子。

这必然会错过很多。 当您实际使用 FRP 系统时，这个比喻很快就会崩溃。 其一，通常也会尝试对离散事件进行建模（例如，单击鼠标）。 我将其放在这里只是为了让您了解它是什么样的。

Answer 4

对我来说，符号 = 有两种不同的含义：

1. 在数学中，x = sin(t) 意味着，x 是不同的sin(t) 的名称。 所以写x + y与sin(t) + y是一样的。 在这方面，函数反应式编程就像数学：如果您编写 x + y，它将使用使用时的 t 值进行计算。
2. 在类似 C 的编程语言（命令式语言）中，x = sin(t) 是一个赋值：这意味着 x 存储值 sin(t) 在赋值时获取。

Answer 5

好的，从背景知识和阅读您指出的维基百科页面来看，反应式编程似乎类似于数据流计算，但具有特定的外部“刺激”触发一组节点来触发并执行其计算。

这非常适合 UI 设计，例如，触摸用户界面控件（例如音乐播放应用程序上的音量控件）可能需要更新各种显示项目和音频输出的实际音量。 当您修改音量（比如说滑块）时，这将对应于修改与有向图中的节点关联的值。

具有来自该“体积值”节点的边缘的各种节点将自动被触发，并且任何必要的计算和更新将自然地影响到应用程序。 应用程序对用户刺激做出“反应”。 函数式反应式编程只是用函数式语言或通常在函数式编程范例中实现这个想法。

有关“数据流计算”的更多信息，请在维基百科上搜索这两个词或使用您最喜欢的搜索引擎。 总体思路是这样的：程序是一个节点有向图，每个节点执行一些简单的计算。 这些节点通过图链接相互连接，这些链接将某些节点的输出提供给其他节点的输入。

当节点触发或执行其计算时，连接到其输出的节点的相应输入被“触发”或“标记”。 任何所有输入已触发/标记/可用的节点都会自动触发。 该图可能是隐式的或显式的，具体取决于反应式编程的实现方式。

节点可以被视为并行触发，但它们通常是串行执行或并行性有限（例如，可能有几个线程执行它们）。 一个著名的例子是曼彻斯特数据流机，它（IIRC）使用标记数据架构来通过一个或多个执行单元调度图中节点的执行。 数据流计算非常适合异步触发计算从而产生级联计算的情况，这种情况比尝试由时钟（或多个时钟）控制执行效果更好。

反应式编程引入了这种“级联执行”的想法，并且似乎以类似数据流的方式来思考程序，但附带条件是一些节点与“外部世界”挂钩，并且当这些感知到时会触发级联执行。类似节点发生变化。 程序执行看起来就像是类似于复杂的反射弧。 该程序可能会或可能不会在刺激之间基本固着，或者可能在刺激之间进入基本固着状态。

“非反应式”编程将以非常不同的执行流程和与外部输入的关系的视图进行编程。 这可能有点主观，因为人们可能会忍不住说任何对外部输入做出反应的东西都会对他们“做出反应”。 但从本质上看，以固定时间间隔轮询事件队列并将发现的任何事件分派给函数（或线程）的程序反应性较低（因为它仅以固定时间间隔处理用户输入）。 再次强调，这就是这里的精神：可以想象将具有快速轮询间隔的轮询实现放入非常低级别的系统中，并在其之上以响应式方式进行编程。

Answer 6

在阅读了许多有关 FRP 的页面后，我终于遇到了这个关于FRP的文章很有启发性，它终于让我明白了FRP的真正含义。

我在下面引用了 Heinrich Apfelmus（《活性香蕉》的作者）的话。

函数式反应式编程的本质是什么？

一个常见的答案是“FRP 就是用
时变函数而不是可变状态的术语”，并且
肯定不会错。 这就是语义观点。 但在
我认为，更深入、更令人满意的答案是
遵循纯粹的语法标准：

函数式反应式编程的本质是在声明时完全指定值的动态行为。

例如，以计数器为例：您有两个按钮
标记为“Up”和“Down”，可用于递增或递减
柜台。 必须首先指定一个初始值
然后每当按下按钮时更改它； 像这样的东西：

counter := 0 -- 初始值 
  on ButtonUp = (counter := counter + 1) -- 稍后更改 
  on ButtonDown = (计数器 := 计数器 - 1) 
  

重点是在声明的时候，只有初始值
对于指定的计数器； 计数器的动态行为是
隐含在程序文本的其余部分中。 相比之下，功能性
反应式编程指定了当时的整个动态行为
声明，如下所示：

计数器::Behavior Int 
  计数器 = 累加 ($) 0 
              (fmap (+1) 事件向上 
               `union` fmap (减去 1) eventDown) 
  

每当你想了解计数器的动态时，你只需
看看它的定义。 一切可能发生的事情都会发生
出现在右侧。 这与
命令式方法，后续声明可以改变
先前声明的值的动态行为。

因此，根据我的理解，FRP 程序是一组方程：

j 是离散的：1,2,3,4...

< code>f 取决于 t，因此这包含了对外部刺激进行建模的可能性，

程序的所有状态都封装在变量 x_i 中

FRP 库负责处理进展时间，换句话说，将 j 带到 j+1。

我在此视频中更详细地解释了这些方程。

编辑：

在原始答案大约两年后，最近我得出的结论是 FRP 实现还有另一个重要方面。 他们需要（并且通常确实）解决一个重要的实际问题：缓存失效。

x_i-s 的方程描述了依赖图。 当某些 x_i 在时间 j 发生变化时，并非所有其他 x_i' 值在 j+1 都需要需要更新，因此并非所有依赖项都需要重新计算，因为某些 x_i' 可能独立于 x_i。

此外，发生变化的 x_i-s 可以增量更新。 例如，让我们考虑 Scala 中的映射操作 f=g.map(_+1)，其中 f 和 g 是 List 的整数。 这里f对应于x_i(t_j)，g对应于x_j(t_j)。 现在，如果我在 g 前面添加一个元素，那么对 g 中的所有元素执行 map 操作将是一种浪费。 一些 FRP 实现（例如 reflex-frp) 旨在解决这个问题。 这个问题也被称为增量计算。

换句话说，行为（x_i< /code>-s ）在 FRP 中可以被认为是缓存计算。 如果某些 f_i-s 确实发生变化，FRP 引擎的任务就是有效地使这些缓存（x_i-s）无效并重新计算。

Answer 7

Conal Elliott 的论文简单高效的功能反应（直接 PDF，233 KB）是一个相当好的介绍。 相应的库也可以工作。

该论文现已被另一篇论文取代，推拉函数反应式编程 （直接 PDF，286 KB ）。

Answer 8

免责声明：我的答案是在 rx.js 的上下文中 - 一个 JavaScript 的“反应式编程”库。

在函数式编程中，您无需迭代集合中的每个项目，而是将高阶函数 (HoF) 应用于集合本身。 因此，FRP 背后的想法是，不要处理每个单独的事件，而是创建一个事件流（使用 observable* 实现）并对其应用 HoF。 通过这种方式，您可以将系统可视化为连接发布者和订阅者的数据管道。

使用可观察的主要优点是：
i) 它从代码中抽象出状态，例如，如果您希望事件处理程序仅针对每个“n”个事件触发，或者在第一个“n”个事件之后停止触发，或者仅在第一个“n”个事件之后开始触发' 事件，您可以只使用 HoF（分别是过滤器、takeUntil、跳过）而不是设置、更新和检查计数器。
ii) 它提高了代码局部性 - 如果您有 5 个不同的事件处理程序更改组件的状态，您可以合并它们的可观察量并在合并的可观察量上定义单个事件处理程序，从而有效地将 5 个事件处理程序合并为 1 个。这使得它非常有用很容易推断整个系统中的哪些事件会影响组件，因为所有事件都存在于单个处理程序中。

• Observable 是 Iterable 的对偶。

Iterable 是一个延迟消耗的序列 - 每个项目在迭代器想要使用时都会被拉取，因此枚举是由消费者驱动的。

可观察对象是一个延迟生成的序列 - 每个项目在添加到序列时都会被推送给观察者，因此枚举由生产者驱动。

Answer 9

老兄，这真是一个绝妙的主意！ 为什么我在 1998 年时没有发现这一点？ 无论如何，这是我对 Fran 教程的解释。 欢迎提出建议，我正在考虑基于此启动一个游戏引擎。

import pygame
from pygame.surface import Surface
from pygame.sprite import Sprite, Group
from pygame.locals import *
from time import time as epoch_delta
from math import sin, pi
from copy import copy

pygame.init()
screen = pygame.display.set_mode((600,400))
pygame.display.set_caption('Functional Reactive System Demo')

class Time:
    def __float__(self):
        return epoch_delta()
time = Time()

class Function:
    def __init__(self, var, func, phase = 0., scale = 1., offset = 0.):
        self.var = var
        self.func = func
        self.phase = phase
        self.scale = scale
        self.offset = offset
    def copy(self):
        return copy(self)
    def __float__(self):
        return self.func(float(self.var) + float(self.phase)) * float(self.scale) + float(self.offset)
    def __int__(self):
        return int(float(self))
    def __add__(self, n):
        result = self.copy()
        result.offset += n
        return result
    def __mul__(self, n):
        result = self.copy()
        result.scale += n
        return result
    def __inv__(self):
        result = self.copy()
        result.scale *= -1.
        return result
    def __abs__(self):
        return Function(self, abs)

def FuncTime(func, phase = 0., scale = 1., offset = 0.):
    global time
    return Function(time, func, phase, scale, offset)

def SinTime(phase = 0., scale = 1., offset = 0.):
    return FuncTime(sin, phase, scale, offset)
sin_time = SinTime()

def CosTime(phase = 0., scale = 1., offset = 0.):
    phase += pi / 2.
    return SinTime(phase, scale, offset)
cos_time = CosTime()

class Circle:
    def __init__(self, x, y, radius):
        self.x = x
        self.y = y
        self.radius = radius
    @property
    def size(self):
        return [self.radius * 2] * 2
circle = Circle(
        x = cos_time * 200 + 250,
        y = abs(sin_time) * 200 + 50,
        radius = 50)

class CircleView(Sprite):
    def __init__(self, model, color = (255, 0, 0)):
        Sprite.__init__(self)
        self.color = color
        self.model = model
        self.image = Surface([model.radius * 2] * 2).convert_alpha()
        self.rect = self.image.get_rect()
        pygame.draw.ellipse(self.image, self.color, self.rect)
    def update(self):
        self.rect[:] = int(self.model.x), int(self.model.y), self.model.radius * 2, self.model.radius * 2
circle_view = CircleView(circle)

sprites = Group(circle_view)
running = True
while running:
    for event in pygame.event.get():
        if event.type == QUIT:
            running = False
        if event.type == KEYDOWN and event.key == K_ESCAPE:
            running = False
    screen.fill((0, 0, 0))
    sprites.update()
    sprites.draw(screen)
    pygame.display.flip()
pygame.quit()

简而言之：如果每个组件都可以被视为一个数字，那么整个系统就可以被视为一个数学方程，对吗？

Answer 10

Paul Hudak 的书，哈斯克尔表达学派，不仅是一本优秀的书介绍了 Haskell，但它也花了相当多的时间在 FRP 上。 如果您是 FRP 的初学者，我强烈推荐它，让您了解 FRP 的工作原理。

还有看起来像是这本书的新重写（2011 年发布，2014 年更新），哈斯克尔音乐学院。

Answer 11

根据前面的答案，似乎从数学上来说，我们只是以更高的顺序思考。 我们不考虑类型为 X 的值 x，而是考虑函数 x：T → X，其中T是时间的类型，可以是自然数、整数或连续体。 现在，当我们在编程语言中编写 y := x + 1 时，我们实际上指的是等式 y(t) = x(t) + 1。

Answer 12

如前所述，其作用类似于电子表格。 通常基于事件驱动的框架。

与所有“范式”一样，它的新颖性是值得商榷的。

根据我对参与者的分布式流网络的经验，它很容易陷入节点网络中状态一致性的普遍问题，即最终会出现大量振荡并陷入奇怪的循环中。

这是很难避免的，因为某些语义意味着引用循环或广播，并且当参与者网络收敛（或不收敛）在某些不可预测的状态时，可能会非常混乱。

类似地，尽管具有明确定义的边缘，但某些状态可能无法达到，因为全局状态偏离了解决方案。 2+2 可能会也可能不会变成 4，这取决于 2 何时变成 2，以及它们是否保持这种状态。 电子表格具有同步时钟和循环检测。 分布式演员通常不会。

一切都很有趣:)。

Answer 13

我在 Clojure subreddit 上发现了这个关于 FRP 的精彩视频。 即使您不了解 Clojure，也很容易理解。

视频如下：http://www.youtube.com/watch?v=nket0K1RXU4

这是视频第二部分引用的来源： https://github.com/Cicayda/yolk-examples/blob/master/src/yolk_examples/client/autocomplete.cljs

Answer 14

Andre Staltz 的这篇文章是我迄今为止看到的最好、最清晰的解释。

文章中的一些引用：

响应式编程是使用异步数据流进行编程。

最重要的是，您将获得一个令人惊叹的功能工具箱，可以组合、创建和过滤任何这些流。

以下是本文中精彩图表的示例：

Answer 15

它是关于随时间（或忽略时间）的数学数据转换。

在代码中，这意味着函数纯粹性和声明性编程。

状态错误是标准命令范式中的一个大问题。 不同的代码位可能会在程序执行的不同“时间”更改某些共享状态。 这很难处理。

在 FRP 中，您描述（就像在声明式编程中）数据如何从一种状态转换为另一种状态以及触发它的因素。 这允许您忽略时间，因为您的函数只是对其输入做出反应并使用它们的当前值创建一个新值。 这意味着状态包含在转换节点的图（或树）中并且在功能上是纯的。

这大大降低了复杂性和调试时间。

想想数学中的 A=B+C 和程序中的 A=B+C 之间的区别。
在数学中，你描述的是一种永远不会改变的关系。 在一个程序中，它说“现在”A 是 B+C。 但下一个命令可能是 B++，在这种情况下 A 不等于 B+C。 在数学或声明式编程中，无论您要求什么时间点，A 始终等于 B+C。

因此，通过消除共享状态的复杂性并随着时间的推移改变值。 你的程序更容易推理。

EventStream 是一个 EventStream + 一些转换函数。

行为是一个 EventStream + 内存中的某个值。

当事件触发时，通过运行转换函数来更新值。 其产生的值存储在行为存储器中。

行为可以组合起来产生新的行为，这些新的行为是 N 个其他行为的转变。 当输入事件（行为）触发时，该组合值将重新计算。

“由于观察者是无状态的，我们经常需要几个观察者来模拟状态机，就像拖动示例中的那样。我们必须将状态保存在所有相关观察者都可以访问的位置，例如上面的变量路径中。”

引自 - 弃用观察者模式
http://infoscience.epfl.ch/record/148043/files/DeprecatingObserversTR2010。 pdf

Answer 16

关于响应式编程的简短清晰的解释出现在Cyclejs - 响应式编程上，它使用简单且直观的方式样品。

[模块/组件/对象]是反应性的意味着它完全负责
通过对外部事件做出反应来管理自己的状态。

这种方法有什么好处？ 这是控制反转，
主要是因为[模块/组件/对象]对自身负责，使用私有方法相对于公共方法改进了封装。

这是一个很好的起点，但不是完整的知识来源。 从那里你可以跳到更复杂和更深层次的论文。

Answer 17

查看 Rx，.NET 的反应式扩展。 他们指出，使用 IEnumerable 基本上是从流中“拉”。 通过 IQueryable/IEnumerable 进行的 Linq 查询是从集合中“吸取”结果的集合操作。 但使用 IObservable 上的相同运算符，您可以编写“反应”的 Linq 查询。

例如，您可以编写一个 Linq 查询，例如
（来自 MyObservableSetOfMouseMovements 中的 m
其中 mX<100 且 mY<100
选择新点(mX,mY))。

有了 Rx 扩展，就是这样：您的 UI 代码可以对传入的鼠标移动流做出反应，并在您位于 100,100 框中时进行绘制...

Answer 18

FRP 是函数式编程（基于一切都是函数的思想的编程范式）和反应式编程范式（基于一切都是流的思想（观察者和可观察哲学））的组合。 它应该是世界上最好的。

首先查看 Andre Staltz 关于反应式编程的文章。