函数式反应式编程语言规范

Question

我正在考虑在某个时候创建​​一个功能性反应框架。我已经阅读了很多相关内容并看到了一些示例，但我想清楚地了解这个框架必须做什么才能被视为 FRP 扩展/dsl。我并不真正关心实施问题或细节等，但更关心完美世界情况下需要什么。

理想的函数式反应式编程语言的关键操作和品质是什么？

Answer 1

我很高兴您首先询问规范而不是实现。
关于玻璃钢是什么，有很多想法。
从 20 世纪 90 年代初开始（当时我在 Sun Microsystems 和 Microsoft Research 从事交互式图形工作），它就涉及两个属性（a）外延性和（b）时间连续性。
许多人放弃了这两个属性，并用各种实现概念来识别 FRP，所有这些在我看来都不是重点。
为了减少混乱，我希望看到术语“函数式反应式编程”被更准确的“函数式反应式编程”所取代。描述性“指示性连续时间编程”(DCTP)，如 Jake McArthur 在 a 中所建议的去年的谈话。

我所说的“指示性”是指建立在精确、简单、独立于实现的组合语义的基础上，它准确地指定了每种类型和构建块的含义。
然后，语义的组合性质决定了构建块的所有类型正确组合的含义。
对我来说，外延是心和心。函数式编程的本质，也是实现精确和精确的原因。易于处理的推理，从而为正确性、推导和优化奠定了基础。
Peter Landin 建议使用“指示性”作为模糊术语“函数式”的实质性替代，也是一种区分深度/真正的函数式编程与仅仅是函数式符号的方法。
请参阅此评论了解一些 Landin引用和论文参考。

关于连续时间，请参阅帖子 为什么要使用连续时间进行编程？ 以及我在本页 AshleyF 的回答中的引用。
我很惊讶&考虑到计算机的离散性质，连续时间的想法在某种程度上是不自然的或不可能实现的。
这种思路让我觉得很奇怪，特别是当来自 Haskellers 时，原因如下：

• 使用惰性函数语言，我们随意地在有限上使用无限数据进行编程 机器。结果我们得到了可爱的模块化，正如 John Hughes 的经典论文 为什么函数式编程很重要。
• 在连续空间中编程的例子有很多，例如矢量图形，还有 Pan 之类的东西。
• 我喜欢我的程序反映我如何看待问题空间而不是执行程序的机器，并且我倾向于期望其他高级语言程序员也有这种偏好。
  （“当程序需要关注不相关的内容时，编程语言就是低级的。” - Alan Perlis）

自从 TBAG 和 ActiveVRML（第一个 DCTP/FRP 系统）和稍后Fran。
正确实施很容易。
连续建模动画的功能实现论文中描述了几种不同的方法。
高效（并且仍然正确！）实现连续时间是另一回事，尤其是避免重新计算不变的值。
（请参阅论文推拉函数反应式编程。 ）

相关备注，请参阅我对反应式编程和函数式反应式编程之间的区别以及什么是（函数式）反应式编程？ 更新：有关连续时间为何如此重要的更多信息，请参阅这些注释。 更新：另请参阅我 2015 年的演讲 FRP 的本质和起源（以及链接的相关讨论）。

祝您探索顺利，如果您有任何疑问，请告诉我。
我的联系信息位于我的主页。

Answer 2

我想您可能已经看过 Matthias Felleisen 的关于函数式 I/O 的演讲并阅读了 他的论文。我认为他的做法非常务实且美好。希望您也偶然发现了 Conal Elliott 的一些出色作品。

我个人的要求是系统是完全纯净的。也就是说，所有行为均由纯 world->world 函数定义，所有实现或可视化均由 world->visual 函数定义；其中视觉是系统输出的一些静态描述。

我的另一个主要功能是历史调试器。维护世界状态的历史并能够从任何时间点重播应该是相对简单的。

一个非常有趣的研究领域（我相信这是一个未解决的问题）是使用连续时间，而不是在一些离散时钟滴答上迭代world->world函数。我曾经写过一些关于 FRP 的博客文章和Conal Elliott 留下了以下发人深省的评论：

我喜欢指示性/功能性
方法，用于可组合性和
语义清晰。对于同样的
原因，我更喜欢连续时间&
离散时间上的空间 &空间。在
所有这些情况，越少
类似机器的配方很好
将“内容”与“如何”分开
基于机器的演示。

解决这个问题，你就会成为英雄！

Answer 3

好吧，除非完美世界指的是心灵感应计算机（哎呀！），那么您将需要某种方式来处理用户 I/O -我假设像正交持久性这样的东西已经包含了更无聊的文件 I/O...

让我们从输入开始...因为它已经有了一个解决方案。摘自 Conal Elliott 和 Paul Hudak 的开创性论文第 4 页（共 11 页）功能响应式动画：

lbp; rbp : Time → Event _{Event ( )}

在 Haskell 中，看起来像这样：

 -- read left and right mouse button-press events
lbp, rbp :: Time -> Event (Event ())

因此对于键盘输入：

kbd :: Time -> Event Char.

其他输入可以在类似的时尚。

那么……输出呢？实际的单词并没有出现在论文的任何地方（“I/O”也没有出现）——我们必须自己解决这个问题。但这一次，是我们的 Haskell 翻译：

lbp, rbp :: Time -> Event (Event ())

提供提示 - Event () - unit-event。这可以作为发送 Char 的结果，出现在屏幕上的某个位置：

viewChar :: Char -> Time -> Event ()

同样，可以使用类似的技术处理其他输出。

---

...那是什么 - 它不是外延的？
因为 viewChar 是...什么 - 不纯？
如果是这样，那就意味着 lbp 和 rbp 也是不纯的 - 您确定吗？

好吧...让我们有一个类型来接收一系列鼠标按钮按下或其他事件：

type Intake a = [a]

lpb, rbp :: Intake (Event (Event ())

那更好吗？好的！嗯，有点——
如果拔掉鼠标会发生什么？那
可以将程序的某些部分置于旋转状态以等待输入（并且使用 [] 将永久结束该系列 - 不再需要按下按钮！）。

我们需要更改Intake：

data Intake a = None (Intake a) | Next a (Intake a) 

现在拔掉鼠标会导致None ...
出现，程序可以检测到并做出相应反应，例如产生其操作系统线程，
那么，输出呢

？好吧，输出设备通常也可以拔掉。从Intake得到提示：

data Outlet a = Wait (Outlet a) | Went (… (Outlet a) …) 

这类似于拔掉输入设备 - 当遇到
Wait ...时，程序可以暂停传输。

那么 Went 的类型应该是什么？嗯，Outlet 逐渐接受值，以便在需要时允许出现 Wait ... - 接受每个值应该向我们提供其余的 Output >。因此：

data Outlet a = Wait (Outlet a) | Went (a -> Outlet a)

总而言之：

data Intake a = None (Intake a) | Next a (Intake a)

lbp, rbp :: Intake (Event (Event ())


data Outlet a = Wait (Outlet a) | Went (a -> Outlet a)

viewChar :: Outlet Char

那么这一切都有效吗？如果您不确定，请参阅 的第 20.4.2 节（第 86 页，共 263 页） Fudgets - 纯功能流程与图形用户界面的应用 作者：Magnus Carlsson 和 Thomas Hallgren - 如果 Intake 和 Outlet 看起来可疑，那么在那里可以看到的内容也是如此，在报纸上...

---