Reactive programming
原文: (英訳はむずい... いや、英語ができないのがヤバイ ...)
リアクティブプログラミング(以下 "RP")は、データフローと変化の伝播を志向とするプログラミングのパラダイムです。
これは、プログラムで、『静的または動的なデータフローを楽に実装できなければいけない事』と
『実行モデルが自動でデータフローに合わせて変化の伝播をできなければいけない』ものです。
例）
-
a := b + c の式があった場合, aは b+c の結果を、式の評価があった時に格納をします。評価後で、b,cは a には影響を与えずに変更できます。そして、a の値は、関数型プログラミングとは反対で、新しいb,cの値で自動的に更新(破壊的代入)します
-
最近のスプレッドシートは"RP"の一つの例です。"=B1+C1"の式は自動的に更新をします
もう一つは、ハードウェア記述言語のVerilogは回路の伝播のモデルを記述できます -
"RP"は、ユーザーインターフェイスやリアルタムアニメーションで使われているが、一般的なプログラミングのパラダイムとなります
-
MVCでは、"PR"によってModelの変更をViewに通知（その逆も）しているとも挙げられます。
コンセプト
明示の程度
"PR"は、矢印でデータフローを明示化できます。
データフローは、命令型や関数型言語の構造に暗黙的に似た形に成ります。
アーキテクチャレベルでは、データフローグラフの独立したノードの相互通信プログラムを表す時もあります。
Static or Dynamic
"PR"は純粋な静的なデータフロー形成と実行中のデータフローの動的な変更が可能です
Higher-order "PR"
別のデータフローからデータフローを構築可能な時、上位"Hight-order"と言えます。
結果は、最初のデータフローと同じ評価モデルで、もう一つのデータフローの結果を出力します。
データフローの識別/差別
理想では、データの変更は即座に全て伝播したいが、現実的には難しい。
その代替えで、データフローの識別/差別をし、評価の優先度を決める必要があるかもしれません。
データフローの識別/差別は複雑な設計を招きます
例）
- ワードプロセッサのスペルチェックが挙げられます
"PR"のモデルの評価
"PR"の評価は、必ずしもスタックベースのプログラムの評価と同じになりません。
それよりも、いくつかのデータ変更があった時に、すべてのデータに部分的または完全に伝播されます。
変換の伝播は、多分、一番自然な方法では無効化/遅延有効化計画で行われます。
それは、もし不確定なデータ形式だと指数関数的な複雑な更新のため、スタックを使った自然な伝播では問題となります。
一つのそのようなデータ形式"repeat diamond shape" (An → Bn → An+1、An → Cn → An+1 n=1,2...)があります。
この問題は、データが無効でないものへの伝播を無効化し、後で必要なものを遅延評価で有効化することで、解決できます。
この"PR"固有の問題は、主要な計算です。通常のプログラミング言語は評価し、問題を考えません。
また、データがメモリを使用し"PR"では多くのメモリを占有します。研究によってこの問題は解決しました。
一方で、"PR"は"明示的な並列"の記述と並列にハードウェアのパワーを利用するものとして使用できます。
オブザーブパターンとの類似について
"PR"はOOPでのオブザーブパターンと類似しています。
けれども、プログラム言語の中でのデータフローの統合は、表現を容易にして、データフローの粒度として扱えるようにしています。
例えば、オブザーブパターンでは、オブジェクト/クラスの間のデータフローを記述すしますが
”OOPR”では オブジェクト/クラスのメンバーをターゲットにできます。
スタックベースの一般的なオブジェクト志向のデータフローの伝播は不完全です。
"tree feedback edges" のデータ構造は指数関数的な問題に直面します。
しかし、比較的限られた使用と小さな粒度のため、オブザーブパターンで大きな問題とし扱われません。
アプローチ
命令型
リアクティブデータ構造で動作するように記述します。それは、制約命令プログラミングと似ています。
注意事項として、制約命令プログラミングは双方向の制約ですが、"PR"は一方向の制約になります。
オブジェクト志向
オブジェクトにリアクションを設定して、リアクションによって再評価が行われて自動的に更新する
関数型
Functional reactive programming (FRP) というパラダイムになります。
ここまで
<反省> 英語を勉強せねば・・・ (;o;)