[解決済み] 現在のFunctional Reactive Programmingの実装状況について教えてください。

質問

私はHaskellでいくつかの簡単な自動物理システム（振り子、ロボットアームなど）を視覚化しようとしています。 多くの場合、これらのシステムは次のような方程式で記述することができます。

df/dt = c*f(t) + u(t)

ここで u(t) はある種の「インテリジェント制御」を表します。これらのシステムは、Functional Reactive Programming のパラダイムに非常にうまく適合しているように見えます。

そこで私は、Paul Hudak氏の著書「The Haskell School of Expression"」を手に取りました。 で紹介されているドメイン固有の言語 "FAL" (Functional Animation Language の略) が、私の単純なおもちゃのシステムで実際に非常に快調に動作することがわかりました (ただし、いくつかの関数、特に integrate をはじめとするいくつかの関数は、効率的な使用には少し怠けすぎているようですが、簡単に修正できます）。

私の質問は、より高度な、あるいは今日の実用的なアプリケーションのための、より成熟した、最新の、よくメンテナンスされた、パフォーマンスチューニングされた代替品は何かということです。

この wiki ページ にはHaskellのオプションがいくつか掲載されていますが、以下の点についてはよくわかりません。

1. このプログラミングパラダイムの発明者の一人である (と私が理解している) Conal Eliott のプロジェクトである "reactive" の状況は、少し陳腐に見えます。私は彼のコードが大好きなのですが、他のもっと新しい選択肢を試すべきでしょうか？構文/パフォーマンス/ランタイムの安定性の観点から、それらの間の主な違いは何ですか？

2. からの引用ですが 調査 の2011年、第6節、"。 ... FRPの実装は、遅延保証を必要とする領域で効果的に使用するためには、まだ十分に効率的ではなく、性能も予測可能ではありません ... というものです。この調査では、いくつかの興味深い最適化の可能性が示唆されていますが、FRPが15年以上存在しているという事実を考えると、この性能の問題は何かあるのではないかという印象を受けます。 非常に あるいは、少なくとも数年以内に解決するのは本質的に難しいという印象を受けます。これは本当でしょうか？

3. この調査の同じ著者は、"time leaks"について、彼の ブログ . この問題はFRPに特有のものでしょうか、それとも純粋で非厳密な言語でプログラミングするときに一般的に抱えているものでしょうか？十分なパフォーマンスがない場合、FRP ベースのシステムを長期間安定させることがあまりにも困難であることを発見したことがありますか？

4. これはまだ研究レベルのプロジェクトなのでしょうか？プラントエンジニア、ロボットエンジニア、金融エンジニアなどの人たちは、実際に（自分たちのニーズに合った言語で）使っているのでしょうか？

個人的にはHaskellの実装を希望していますが、他の提案も歓迎します。例えば、Erlangの実装があれば特に楽しいでしょう。そうすれば、インテリジェントで適応性があり、自己学習するサーバープロセスを持つことがとても簡単になるでしょう

どのように解決するのですか？

現在、関数型リアクティブプログラミングのための実用的なHaskellライブラリは、主に2つあります。 どちらも一人でメンテナンスされていますが、他のHaskellプログラマからもコードのコントリビューションを受けています。

• ネットワイヤー は、効率性、柔軟性、予測可能性に重点を置いています。 独自のイベントパラダイムを持ち、ネットワークサービスや複雑なシミュレーションなど、従来のFRPが機能しない領域で使用することができます。 スタイル：アプリケーティブおよび/またはアローライズド。 最初の作者とメンテナ。Ertugrul Söylemez (これは私です)。

• リアクティブバナナ は、伝統的なFRPのパラダイムを基に構築されています。 実用的である一方、古典的な FRP 研究のための基盤としても機能します。 主な焦点はユーザインターフェイスで、wxへの既製のインターフェイスがあります。 スタイル: アプリケーティブ。 最初の作者とメンテナ。Heinrich Apfelmus。

どちらも試してみるべきですが、用途によってはどちらか一方がより適していることが分かるでしょう。

ゲーム、ネットワーキング、ロボット制御、シミュレーションなどでは、Netwireが便利だと感じるでしょう。 これは、既製の <項目 ワイヤー は、そのようなアプリケーションのために、様々な便利な微分、積分、そして透過的なイベント処理のための多くの機能を含んでいます。 チュートリアルは Control.Wire モジュールのドキュメントをご覧ください。

グラフィカルユーザーインターフェースのために、現在あなたの最良の選択はreactive-bananaです。 これはすでに wx インターフェイスを持っており (別のライブラリ reactive-banana-wx として)、Heinrich はコードサンプルを含むこの文脈での FRP について多くのブログを書いています。

他の質問に答えます。 FRP は、リアルタイムの予測可能性が必要なシナリオには適していません。 これは主に Haskell によるものですが、残念ながら FRP は低レベルの言語では実現が困難です。 Haskell自体がリアルタイムに対応できるようになれば、FRPも対応できるようになるでしょう。 概念的にはネットワイヤーはリアルタイムアプリケーションに対応している。

タイムリークはモナドフレームワークに大きく関わってくるので、もうあまり問題ではない。 実用的な FRP 実装は、単にモナド的なインターフェイスを提供していないだけです。 Yampaがこれを始め、Netwireとreactive-bananaの両方がその上に構築されています。

今現在、FRPを使用した商業的またはその他の大規模なプロジェクトは知りません。 ライブラリは準備できていますが、人々はまだそうではないようです。