功能響應式編程語言規范

Question

我正在考慮在某個時候創建一個功能性反應框架。 我已經閱讀了很多關於它的內容並看到了一些示例，但我想清楚地了解這個框架必須做什么才能被視為 FRP 擴展/dsl。 我並不真正關心實施問題或細節等，而是更關心在完美世界情況下需要什么。

理想的函數式反應式編程語言的關鍵操作和品質是什么？

Answer 1

我很高興您首先詢問規范而不是實施。 關於 FRP 是什么，有很多想法。 對我來說，這一直是兩件事：（a）外延和（b）時間連續。 許多人放棄了這兩個屬性，並用各種實現概念來識別 FRP，在我看來，所有這些都是無關緊要的。 為了減少混淆，我希望看到術語“函數式反應式編程”被更准確和描述性的“指示性、連續時間編程”（DCTP）取代，正如 Jake McArthur 在去年的一次談話中所建議的那樣。

通過“外延”，我的意思是建立在精確、簡單、獨立於實現的組合語義之上，該語義准確地指定了每種類型和構建塊的含義。 然后，語義的組合性質決定了構建塊的所有類型正確組合的含義。 對我來說，外延是函數式編程的核心和本質，是實現精確和易於推理的原因，因此是正確性、推導和優化的基礎。 Peter Landin 建議將“外延”作為模糊術語“函數式”的實質性替代，以及一種將深度/真正函數式編程與僅僅具有函數式外觀的符號區分開來的方法。 有關 Landin 的一些引述和論文參考，請參閱此評論。

關於連續時間，請參閱帖子為什么要使用連續時間進行編程？ 以及我在此頁面上 AshleyF 的回答中的引述。 考慮到計算機的離散性，聽到連續時間的想法在某種程度上不自然或不可能實現的說法，我一次又一次地感到驚訝。 這種思路讓我覺得很奇怪，尤其是來自 Haskellers 時，原因如下：

• 使用惰性函數式語言，我們隨意地在有限機器上用無限數據進行編程。 結果，我們得到了可愛的模塊化，正如 John Hughes 的經典論文Why Functional Programming Matters中所說明的那樣。
• 在連續空間中編程的例子有很多，例如矢量圖形，還有Pan之類的東西。
• 我喜歡我的程序反映我對問題空間的看法，而不是對執行程序的機器的看法，我傾向於期望其他高級語言程序員也能分享這種偏好。 （“當程序需要關注不相關的內容時，編程語言是低級的。” - Alan Perlis）

自TBAG和ActiveVRML （第一個 DCTP/FRP 系統）和后來的Fran以來，我一直在制作用於連續時間編程的庫。 很容易正確實施。 連續建模 Animation 的功能實現一文中描述了幾種不同的方法。 有效地（並且仍然正確地）實施連續時間是另一回事。 特別是避免重新計算不變的值。 （請參閱論文推拉功能反應式編程。）

有關相關說明，請參閱我對響應式編程和功能響應式編程之間的區別和什么是（功能）響應式編程？ 更新：有關連續時間為何重要的更多信息，請參閱這些說明。 更新：另見，我的 2015 年演講FRP 的本質和起源（以及鏈接在那里的相關演講）。

祝您探索順利，如果您有任何問題，請告訴我。 我的聯系信息在我的主頁上。

Answer 2

我假設您可能已經看過Matthias Felleisen 關於函數式 I/O 的演講並閱讀了他的論文。 我認為他是一個非常務實和美麗的方法。 希望您也偶然發現了Conal Elliott的一些出色作品。

我個人的要求是系統是完全純凈的。 也就是說，所有的行為都是由純world->world函數定義的，所有的實現或可視化都是由world->visual函數定義的； 其中visual是來自系統的output的一些 static 描述。

我的另一個主要功能是歷史調試器。 維護world狀態的歷史並能夠從任何時間點重播應該是相對微不足道的。

一個非常有趣的研究領域（我相信一個未解決的問題）是使用連續時間，而不是在一些離散的時鍾滴答上迭代world->world函數。 我曾經在 FRP 上發表過幾篇博文， Conal Elliott留下了以下發人深省的評論：

我喜歡指稱/功能方法，以實現可組合性和語義清晰。 出於同樣的原因，我更喜歡連續的時間和空間而不是離散的時間和空間。 在所有這些情況下，不太像機器的公式很好地將其基於機器的演示的內容與方式分開。

解決這個問題，您將成為英雄！