问函数式反应式程序设计语言规范

EN

我很高兴您从询问规范开始，而不是首先询问实现。关于FRP是什么，有很多想法。从90年代初开始(当时我在Sun Microsystems和微软研究院从事交互式图形工作)，它一直是关于两个属性(a)表示和(b)时间连续。许多人放弃了这两个属性，并将FRP与各种实现概念联系起来，所有这些在我看来都不是重点。为了减少混淆，我希望看到术语“函数式反应式编程”被更准确和描述性更强的“指代，连续时间编程”(DCTP)所取代，正如Jake在a conversation last year中所建议的那样。

我所说的“指示性”，是指建立在精确的、简单的、独立于实现的、精确地指定每种类型和构建块的含义的组合语义之上的。然后，语义的组合性质决定了构建块的所有类型正确组合的含义。对我来说，指示性是函数式编程的核心和本质，是实现精确和易于处理的推理的基础，因此是正确性、派生和优化的基础。Peter Landin建议将“指示性”作为更模糊的术语“函数式”的实质性替代，并将深度/真正的函数式编程与仅看起来函数式的符号区分开来。有关一些兰丁引文和论文参考，请参阅this comment。

关于continuous time，请参阅本页上的帖子和我在AshleyF的答案中的引述。我一次又一次地听到这样的说法，即考虑到计算机的离散性质，连续时间的想法不知何故是不自然的，或者是不可能实现的。这种想法让我觉得很奇怪，尤其是来自Haskellers的时候，原因如下：

• 使用懒惰的函数式语言，我们可以在有限的机器上随意编写无限数据的程序。因此，我们得到了可爱的模块化，就像John Hughes的经典论文.
• There是许多连续空间编程的例子，例如，矢量图形，但也有像Pan.
• I这样的东西，比如我的程序，反映了我对问题空间的看法，而不是执行程序的机器，我倾向于期望其他高级语言程序员也有这种偏好。(“当一种编程语言的程序需要注意不相关的东西时，它就是低级的。”--艾伦·佩利斯)

从TBAG和ActiveVRML (第一个DCTP/FRP系统)到后来的Fran，我一直在为连续时间的编程制作库。它很容易正确实现。论文中描述了几种不同的方法。有效地实现连续时间(仍然是正确的！)是另一回事，尤其是避免重新计算不变的值。(参见论文。)

有关相关说明，请参阅my answer to 和更新:有关为什么连续时间很重要的更多信息，请参阅these notes。更新:另请参阅我2015年的talk (以及在那里链接的相关谈话)。

祝你的探索好运，如果你有任何问题请告诉我。我的联系方式在my home page上。

我想您可能已经在函数式I/O上见过Matthias Felleisen’s talk，并且读过his paper。我认为他是一种非常务实和美丽的方法。希望你也偶然发现了Conal Elliott的一些优秀作品。

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

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

一个非常有趣的研究领域(我认为是一个未解决的问题)是使用连续时间，而不是在一些离散的时钟节拍上迭代world->world函数。我曾经做过一次few blog posts on FRP，Conal Elliott留下了以下发人深省的评论：

我喜欢表示/函数方法，因为它具有可组合性和语义清晰度。出于同样的原因，我更喜欢连续的时间和空间，而不是离散的时间和空间。在所有这些情况下，不太像机器的公式很好地区分了基于机器的表示的内容和方式。

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