Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
リアクティブ
プログラミング
情報通信研究機構
⾼野 祐輝
元ネタ
➤ Engineer Bainomugisha, et al.,“A Survey on Reactive Programming”, Journal
of ACM Computing Surveys, Volume 45 Issue ...
リアクティブプログラミング
➤ イベントを扱うためのプログラミングモデル
➤ Fran(原点)
➤ Haskellのライブラリとして提供
➤ 2Dや3Dのインタラクティブなアニメーションを扱うために⽣まれた
➤ イベントのモデル化
➤ ELLI...
コールバックベースなプログラミングの問題点
➤ 多くの独⽴したコード⽚が同じデータを操作する
➤ 実⾏順が予測不可能
➤ コールバック関数は返り値を持たないため、アプリケーションの状態に副作⽤を及ぼす必要がある(グ
ローバル変数)
➤ あるAd...
最近の流れ
➤ リアクティブプログラミングを利⽤したライブラリが登場してきた
➤ FacebookのReact.js
➤ .NETの.NET RX
➤ RxJS
➤ Frapjax
➤ RxSwift
5
リアクティブ
プログラミングと
その特徴
リアクティブプログラミングにおける抽象化
➤ Behaviors
➤ 時間的に変化する値
➤ 時間経過に伴い連続的に変化する
➤ Events
➤ 時間順に並ぶ離散的な値
7
t
event stream x
event stream y
be...
Behaviorsの評価戦略
➤ 遅延評価
➤ Haskellのリアクティブプログラミング(Fran、Yampa)など
➤ 必要になった時に計算が⾏われるので無駄がない
➤ 正格評価
➤ 正格評価する⾔語も多い
➤ 無駄な計算を省くためサンプリ...
Behaviorsの評価モデル、pullとpush(1)
➤ pullベース
➤ 利点
➤ 必要となる時のみ計算すれば良い
➤ Fran、YampaではHaskellの遅延評価を利⽤
➤ ⽋点
➤ イベントの配送遅延
➤ pushベースの実装
...
Behaviorsの評価モデル、pullとpush(2)
➤ pushベース
➤ 利点
➤ イベントの配送遅延はない
➤ ⽋点
➤ 無駄な再計算を⾏う可能性あり
➤ 例えば、GUIのウィンドウがバックグラウンドであるときは、GUIに関する計算を...
Behaviorsの評価モデル、pullとpush(3)
➤ pull v.s. push
➤ pullの場合、behaviorsの初期値を決定しなくて良いのも利点
➤ pushだと初期値が必要
➤ (しかし、初期値を決定しないとイベントの⼊⼒...
グリッチとその対策(1)
➤ グリッチとは
➤ パルス的に起きる電気的ノイズ
➤ 接触不良
➤ 電気素⼦の劣化などが原因
➤ Behaviorsが⼀瞬だけ間違っている場合がある
➤ COOPER, G. H. AND KRISHNAMURTHI...
グリッチとその対策(2)
➤ グリッチの例
➤ 次のようなリアクティブプログラミングを考えてみる
➤ var1が2に変化した時なにが起きるか?
➤ 論理的には、var3はvar2の2倍(var3 = 2×var2)
➤ しかし、イベント配送のタ...
グリッチとその対策(3)
14
A Survey on Reactive Programming
1
*
1
var1
1
var2
2
var3
+
2
*
1
var1
1
var2
3
var3
+
2
*
1
var1
2
var2
4...
グリッチとその対策(4)
➤ topologically sorted graphで解決できるらしい(要調査)
➤ COOPER, G. H. AND KRISHNAMURTHI, S. 2006. “Embedding dynamic dat...
リフティングとその戦略(1)
➤ 既存のホスト⾔語にリアクティブプログラミングが導⼊された場合に、リフティン
グと呼ばれる操作が必要となる
➤ リフティングで何をするか?
➤ +、ー、*、/などのプリミティブな演算に対するリアクティブプログラミ...
リフティングとその戦略(2)
➤ リフティングの定義
➤
➤ あるタイムステップ i においては、リアクティブでない普通の関数と等価
17
ments and its return type) and it registers a depend...
リフティングとその戦略(3)
➤ 静的型付け⾔語に対する適⽤
➤ 静的型付けなので、関数を直接変換することは出来ない
➤ プログラマがリフト操作を⾏う必要がある
➤ ⼀般的には⾔語の提供するオーバーロードの機能を⽤いて、なるべく簡単に出来るよう...
リフティングとその戦略(4)
➤ 暗黙的リフティング
➤
➤ 動的型付け⾔語で⽤いられる⼿法
➤ 明⽰的リフティング
➤
➤ 静的型付け⾔語で⽤いられる⼿法
➤ オーバーロードなどで対応している場合もこちらに分類
➤ ⼿動リフティング
➤
➤ ...
多⽅向性
➤ イベントの伝達⽅向が、⼀⽅向か双⽅向か
➤ 例:摂⽒華⽒変換
➤ F = C * 1.8 + 32
➤ Cが変化するとFの値が変化(ここまで⼀⽅向)
➤ 上の等式は次のように変換できる
➤ C = (F ー 32) / 1.8
➤...
分散リアクティブプログラミング
➤ 分散環境でのリアクティブプログラミングは達成できるか?
➤ 問題点
➤ ⼀貫性の保証ができるのか?
➤ グリッチの解決が更に難しく
➤ グローバルクロック無し
➤ パケットロス
➤ レイテンシ
21
リアクティブ
プログラミングの種類
Table I. A taxonomy of reactive programming languages
Language Basic abstractions Evaluation
model
Lifting Multidirectiona...
リアクティブプログラミングの分類
24
12 E. Bainomugisha et a
Programming languages
for expressing reactive systems
Synchronous, dataflow and...
関数型リアクティブプログラミング(FRP)
➤ 関数の引数がイベント
➤ 引数の値が変わる(イベントが発⽣する)と⾃動的に関数が呼ばれる
➤ 例:
➤ (draw-circle mouse-x mouse-y)
➤ mouse-x、mouse-...
関数型リアクティブプログラミングの種類
26
rvey on Reactive Programming
Table II. Functional reactive programming (FRP) siblings
Language Host...
関数型でないリアクティブプログラミングの種類
27
y on Reactive Programming
Table III. The cousins of reactive programming
Language Host language
...
リアクティブ
プログラミングの実例
Fran
➤ 1997年に考案された、⼀番初めのリアクティブプログラミング⾔語
➤ ホスト⾔語はHaskell
➤ 関数型リアクティブプログラミング
➤ リフティングは明⽰的に⾏う
➤ ただし、多くの場合でオーバーロードで対応可能
➤ 当初はp...
Franの例(1)
➤ 摂⽒華⽒変換
➤ tempは定義済みのbehavior
30
the need to explicitly lift operators for this particular problem dom
The first ...
Franの例(2)
➤ 円を書く関数
➤ lbp、rbpはevent
➤ withColorは描画関数
➤ circleは事前に定義されたbehavior
31
where
tempC = temp
tempF = (tempC*1.8)+32...
Flapjaxの例(1)
➤ JavaScript上でFRPを実現
➤ pushベース
➤ 関数型リアクティブプログラミング
32
The tempConverter function implements the functionality ...
Flapjaxの例(2)
➤ http://www.flapjax-lang.org/try/index.html?edit=mouse_coords.fx
➤ マウスを動かすとHTMLが勝⼿に更新される謎技術
33
<html>
<head>
...
Trellisの例
➤ Python上で構築された、リアクティブプログラミング環境
➤ glich回避は部分的にされているが、完全ではないらしい?(詳細は調べていない)
➤ push型のモデル
➤ 関数型じゃないリアクティブプログラミング
34...
.NET RXの例
➤ 統合⾔語クエリLINQ上に構築された.NET拡張
➤ イベントソースに対して、IObservable<T>というジェネリックインターフェースを提供
➤ IObservable<T>は、イベントオブザーバを登録するためのメ...
まとめ
まとめ
➤ リアクティブプログラミングというプログラミングパラダイムを紹介
➤ 1997年に登場と、⾔語のモデルとしては⽐較的新しい
➤ オブジェクト指向:1967年、Simula⾔語
➤ ジェネリックプログラミング:1989年
➤ Musse...
EOF
38
Upcoming SlideShare
Loading in …5
×

リアクティブプログラミング

4,170 views

Published on

リアクティブプログラミングについてサーベイした発表資料です。
http://ytakano.github.io/

Published in: Software
  • Dating for everyone is here: ❤❤❤ http://bit.ly/39pMlLF ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❤❤❤ http://bit.ly/39pMlLF ❤❤❤
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Easy and hassle free way to make money online! I have just registered with this site and straight away I was making money! It doesn't get any better than this. Thank you for taking out all the hassle and making money answering surveys as easy as possible even for non-techie guys like me! ▲▲▲ https://bit.ly/2Ruzr8s
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

リアクティブプログラミング

  1. 1. リアクティブ プログラミング 情報通信研究機構 ⾼野 祐輝
  2. 2. 元ネタ ➤ Engineer Bainomugisha, et al.,“A Survey on Reactive Programming”, Journal of ACM Computing Surveys, Volume 45 Issue 4, August 2013, Article No. 52 2
  3. 3. リアクティブプログラミング ➤ イベントを扱うためのプログラミングモデル ➤ Fran(原点) ➤ Haskellのライブラリとして提供 ➤ 2Dや3Dのインタラクティブなアニメーションを扱うために⽣まれた ➤ イベントのモデル化 ➤ ELLIOTT, C. AND HUDAK, P. , “Functional reactive animation”, ICFP '97 Proceedings of the second ACM SIGPLAN international conference on Functional programming 3
  4. 4. コールバックベースなプログラミングの問題点 ➤ 多くの独⽴したコード⽚が同じデータを操作する ➤ 実⾏順が予測不可能 ➤ コールバック関数は返り値を持たないため、アプリケーションの状態に副作⽤を及ぼす必要がある(グ ローバル変数) ➤ あるAdobeのデスクトップアプリでは、バグの半分が、イベント操作のロジック部分と関連(Järvi, J. et al., “Property models: from incidental algorithms to reusable components”, ACM GPCE 2008) ➤ その他資料 ➤ Edwards, J., “Coherent reaction”, ACM SIGPLAN 2009 ➤ MAIER, I., ROMPF, T., AND ODERSKY, M., “Deprecating the Observer Pattern”, Tech report 2010 4
  5. 5. 最近の流れ ➤ リアクティブプログラミングを利⽤したライブラリが登場してきた ➤ FacebookのReact.js ➤ .NETの.NET RX ➤ RxJS ➤ Frapjax ➤ RxSwift 5
  6. 6. リアクティブ プログラミングと その特徴
  7. 7. リアクティブプログラミングにおける抽象化 ➤ Behaviors ➤ 時間的に変化する値 ➤ 時間経過に伴い連続的に変化する ➤ Events ➤ 時間順に並ぶ離散的な値 7 t event stream x event stream y behavior z = x + y 1 5 6 3 2 5 4 6 11 9 5 8 9 エクセル的なモデル
  8. 8. Behaviorsの評価戦略 ➤ 遅延評価 ➤ Haskellのリアクティブプログラミング(Fran、Yampa)など ➤ 必要になった時に計算が⾏われるので無駄がない ➤ 正格評価 ➤ 正格評価する⾔語も多い ➤ 無駄な計算を省くためサンプリングされる場合もある 8
  9. 9. Behaviorsの評価モデル、pullとpush(1) ➤ pullベース ➤ 利点 ➤ 必要となる時のみ計算すれば良い ➤ Fran、YampaではHaskellの遅延評価を利⽤ ➤ ⽋点 ➤ イベントの配送遅延 ➤ pushベースの実装 ➤ Fran、NewFran、Yampa ➤ 最近のNewFranやYampaでは、遅延に関する問題は解決済みらしい 9 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The flow of data Pull-based Push-based Fig. 2. Push- Versus Pull-based evaluation model 3.2. Evaluation Model The evaluation model of a reactive programming language is conc
  10. 10. Behaviorsの評価モデル、pullとpush(2) ➤ pushベース ➤ 利点 ➤ イベントの配送遅延はない ➤ ⽋点 ➤ 無駄な再計算を⾏う可能性あり ➤ 例えば、GUIのウィンドウがバックグラウンドであるときは、GUIに関する計算をする必 要はない。pushベースだと必ず計算する。 ➤ pushベースの実装 ➤ Flapjax、Scala.React、FrTime 10 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The flow of data Pull-based Push-based Fig. 2. Push- Versus Pull-based evaluation model 3.2. Evaluation Model The evaluation model of a reactive programming language is conce changes are propagated across a dependency graph of values and com the programmer’s point of view, propagation of changes happens autom this is the essence of reactive programming. A change of a value shou cally propagated to all dependent computations. When there is an eve an event source, dependent computations need to be notified about the bly triggering a recomputation. At the language level, the design dec to be taken into account is who initiates the propagation of changes. T
  11. 11. Behaviorsの評価モデル、pullとpush(3) ➤ pull v.s. push ➤ pullの場合、behaviorsの初期値を決定しなくて良いのも利点 ➤ pushだと初期値が必要 ➤ (しかし、初期値を決定しないとイベントの⼊⼒待ちが発⽣するので、⼀概に 利点とも⾔えないと思う) ➤ pushだとグリッチが発⽣!(後述) ➤ 両⽅使う実装もある ➤ Lula System, Fran 11 A Survey on Reactive Programming Producer Consumer Push data to the consumer Pull data from the producer The flow of data Pull-based Push-based
  12. 12. グリッチとその対策(1) ➤ グリッチとは ➤ パルス的に起きる電気的ノイズ ➤ 接触不良 ➤ 電気素⼦の劣化などが原因 ➤ Behaviorsが⼀瞬だけ間違っている場合がある ➤ COOPER, G. H. AND KRISHNAMURTHI, S. 2006. “Embedding dynamic dataflow in a call- by-value language”, In ESOPʼ06: Proceedings of the 15th European conference on Programming Languages and Systems. Springer-Verlag, Berlin, Heidelberg, 294–308. 12 -2.5 -2 -1.5 -1 -0.5 0 0.5 1 1.5 2 2.5 -1.6 -1.2 -0.8 -0.4 0.4 0.8 1.2 1.6 電気的なグリッチのイメージ
  13. 13. グリッチとその対策(2) ➤ グリッチの例 ➤ 次のようなリアクティブプログラミングを考えてみる ➤ var1が2に変化した時なにが起きるか? ➤ 論理的には、var3はvar2の2倍(var3 = 2×var2) ➤ しかし、イベント配送のタイミング次第では、var3≠2×var2となる 13 Glitch avoidance is another property that needs to be considered by a reactive lan- guage. Glitches are update inconsistencies that may occur during the propagation of changes. When a computation is run before all its dependent expressions are eval- uated, it may result in fresh values being combined with stale values, leading to a glitch [Cooper and Krishnamurthi 2006]. This can only happen in languages employ- ing a push-based evaluation model. Consider an example reactive program below: var1 = 1 var2 = var1 * 1 var3 = var1 + var2 In this example, the value of the variable var2 is expected to always be the same as that of var1, and that of var3 to always be twice that of var1. Initially when the value of var1 is 1, the value of var2 is 1 and var3 is 2. If the value of var1 changes to, say 2, the value of var2 is expected to change to 2 while the value of var3 is expected to be 4. However, in a naive reactive implementation, changing the value of var1 to 2 may cause the expression var1 + var2 to be recomputed before the expression var1 * 1. Thus the value of var3 will momentarily be 3, which is incorrect. Eventually, the expression var1 * 1 will be recomputed to give a new value to var2 and therefore the value of var3 will be recomputed again to reflect the correct value 4. This behaviour is depicted in Figure 3. In the reactive programming literature, such a momentary view of inconsistent data
  14. 14. グリッチとその対策(3) 14 A Survey on Reactive Programming 1 * 1 var1 1 var2 2 var3 + 2 * 1 var1 1 var2 3 var3 + 2 * 1 var1 2 var2 4 var3 + time var1 = 1 var2 = 1 var3 = 2 var1 = 2 var2 = 1 var3 = 3 var1 = 2 var2 = 2 var3 = 4 nges. When a computation is run before all its dependent expressions are eval- ed, it may result in fresh values being combined with stale values, leading to a ch [Cooper and Krishnamurthi 2006]. This can only happen in languages employ- a push-based evaluation model. onsider an example reactive program below: var1 = 1 var2 = var1 * 1 var3 = var1 + var2 n this example, the value of the variable var2 is expected to always be the same that of var1, and that of var3 to always be twice that of var1. Initially when the ue of var1 is 1, the value of var2 is 1 and var3 is 2. If the value of var1 changes to, 2, the value of var2 is expected to change to 2 while the value of var3 is expected be 4. However, in a naive reactive implementation, changing the value of var1 to ay cause the expression var1 + var2 to be recomputed before the expression var1 . Thus the value of var3 will momentarily be 3, which is incorrect. Eventually, the ression var1 * 1 will be recomputed to give a new value to var2 and therefore the ue of var3 will be recomputed again to reflect the correct value 4. This behaviour is icted in Figure 3. n the reactive programming literature, such a momentary view of inconsistent data nown as a glitch [Cooper and Krishnamurthi 2006]. Glitches result in incorrect pro- m state and wasteful recomputations and therefore should be avoided by the lan- ge. Most reactive programming languages eliminate glitches by arranging expres- 最終的には正しい値に 不必要な計算&値の不整合
  15. 15. グリッチとその対策(4) ➤ topologically sorted graphで解決できるらしい(要調査) ➤ COOPER, G. H. AND KRISHNAMURTHI, S. 2006. “Embedding dynamic dataflow in a call-by-value language”, In ESOPʼ06: Proceedings of the 15th European conference on Programming Languages and Systems. Springer-Verlag, Berlin, Heidelberg, 294–308. ➤ MEYEROVICH, L. A., GUHA, A., BASKIN, J., COOPER, G. H., GREENBERG, M., BROMFIELD, A., AND KRISHNAMURTHI, S. 2009. “Flapjax: a programming language for ajax applications”, In OOPSLA ʼ09: Proceeding of the 24th ACM SIGPLAN conference on Object oriented programming systems languages and applications. ACM, New York, NY, USA, 1–20. ➤ MAIER, I., ROMPF, T., AND ODERSKY, M. 2010. “Deprecating the Observer Pattern”,Tech. rep. ➤ 分散リアクティブプログラミングでは未解決の問題 ➤ ネットワーク障害 ➤ 遅延、パケロス ➤ グローバルクロックが無い ➤ 今後の研究課題 15
  16. 16. リフティングとその戦略(1) ➤ 既存のホスト⾔語にリアクティブプログラミングが導⼊された場合に、リフティン グと呼ばれる操作が必要となる ➤ リフティングで何をするか? ➤ +、ー、*、/などのプリミティブな演算に対するリアクティブプログラミング 対応 ➤ 関数呼び出しに対するリアクティブプログラミング対応 16
  17. 17. リフティングとその戦略(2) ➤ リフティングの定義 ➤ ➤ あるタイムステップ i においては、リアクティブでない普通の関数と等価 17 ments and its return type) and it registers a dependency graph in the taflow graph. In the following definitions, we assume functions that haviour argument for the sake of brevity, generalising to functions le arguments is trivial. lift : f(T) ! flifted(Behaviour < T >) ys, Vol. , No. , Article , Publication date: 2012. リアクティブな値を 扱えない従来の関数を リアクティブな値を取る関数に変換 E. Bainomugisha et al. n, T is a non-behaviour type while Behaviour is a behaviour type ype T. Therefore, lifting an operator f that was defined to operate value transforms it into a lifted version flifted that can be applied aluation of a lifted function f called with a behaviour yielding values fined as follows: flifted(Behaviour < T >) ! f(Ti) the value of Behaviour at time step i. ween Typing and Lifting. In the body of work discussed in this survey, a number of different ways. Before discussing them, it is important interplay between the semantics of the host language and trans- ここで Ti はタイムステップ i におけるBehaviorの値
  18. 18. リフティングとその戦略(3) ➤ 静的型付け⾔語に対する適⽤ ➤ 静的型付けなので、関数を直接変換することは出来ない ➤ プログラマがリフト操作を⾏う必要がある ➤ ⼀般的には⾔語の提供するオーバーロードの機能を⽤いて、なるべく簡単に出来るような⼯ 夫がされている ➤ 動的型付け⾔語に対する適⽤ ➤ 関数については、Behaviorsも普通に引数として受け取れる ➤ ⾔語内部で暗黙的に処理される ➤ プリミティブな演算については、演算⼦オーバーロードや、コード⽣成時に⼯夫が必要 18
  19. 19. リフティングとその戦略(4) ➤ 暗黙的リフティング ➤ ➤ 動的型付け⾔語で⽤いられる⼿法 ➤ 明⽰的リフティング ➤ ➤ 静的型付け⾔語で⽤いられる⼿法 ➤ オーバーロードなどで対応している場合もこちらに分類 ➤ ⼿動リフティング ➤ ➤ ⾔語レベルでのサポート無しの場合は、⼿動で現在のBehaviorsの値をわたす必要がある 19 mplicit lifting approach, when an ordinary language operator it is automatically “lifted”. Implicit lifting makes reactive , since programmers can freely use existing operators on f(b1) ! flifted(b1) ordinary operator f is applied on a behaviour b1, it is implic- the approach undertaken by dynamically typed languages. plicit lifting, the language provides a set of combinators that ry operators to operate on behaviours. lift(f)(b1) ! flifted(b1) nary operator f is explicitly lifted using the combinator lift e behaviour b1. This is the approach that is usually under- languages. In many cases, reactive programming systems f(b1) ! flifted(b1) an ordinary operator f is applied on a behaviour b1, it is implic- is the approach undertaken by dynamically typed languages. xplicit lifting, the language provides a set of combinators that nary operators to operate on behaviours. lift(f)(b1) ! flifted(b1) dinary operator f is explicitly lifted using the combinator lift the behaviour b1. This is the approach that is usually under- d languages. In many cases, reactive programming systems ACM Computing Surveys, Vol. , No. , Article , Publication date: 2012. ogramming :9 oblem domain, for which it offers a rich set of overloaded primi- rk on behaviours. In this survey, we still classify this as explicit n in the discussion of the language in question when primitive ded to deal with behaviours. th manual lifting, the language does not provide lifting operators. mer needs to manually obtain the current value of a time-varying be used with ordinary language operators. f(b1) ! f(currentvalue(b1)) current value of the time-varying value b1 is obtained that is then operator f. In languages that do not offer first-class behaviours,
  20. 20. 多⽅向性 ➤ イベントの伝達⽅向が、⼀⽅向か双⽅向か ➤ 例:摂⽒華⽒変換 ➤ F = C * 1.8 + 32 ➤ Cが変化するとFの値が変化(ここまで⼀⽅向) ➤ 上の等式は次のように変換できる ➤ C = (F ー 32) / 1.8 ➤ Fが変化するとCも変化すると双⽅向 ➤ 制約プログラミングと似ている 20
  21. 21. 分散リアクティブプログラミング ➤ 分散環境でのリアクティブプログラミングは達成できるか? ➤ 問題点 ➤ ⼀貫性の保証ができるのか? ➤ グリッチの解決が更に難しく ➤ グローバルクロック無し ➤ パケットロス ➤ レイテンシ 21
  22. 22. リアクティブ プログラミングの種類
  23. 23. Table I. A taxonomy of reactive programming languages Language Basic abstractions Evaluation model Lifting Multidirectionality Glitch avoidance Support for distribution FRP Siblings Fran behaviours and events Pull Explicit N Y N Yampa signal functions and events Pull Explicit N Y N FrTime behaviours and events Push Implicit N Y N NewFran behaviours and events Push and Pull Explicit N Y N Frapp´e behaviours and events Push Explicit N N N Scala.React signals and events Push Manual N Y N Flapjax behaviours and events Push Explicit and implicit N Y (local) Y AmbientTalk/R behaviours and events Push Implicit N Y (local) Y Cousins of Reactive Programming Cells rules, cells and ob- servers Push Manual N Y N Lamport Cells reactors and reporters Push and Pull Manual N N Y SuperGlue signals, components, and rules Push Manual N Y N Trellis cells and rules Push Manual N Y* N Radul/Sussman Propagators propagators and cells Push Manual Y N N Coherence reactions and actions Pull N/A Y Y N .NET Rx events Push Manual N N? N
  24. 24. リアクティブプログラミングの分類 24 12 E. Bainomugisha et a Programming languages for expressing reactive systems Synchronous, dataflow and synchronous dataflow languages The cousins of reactive proramming The FRP siblings Fig. 4. Classification of languages for reactive programming. pen in one direction. We further discuss the support for multidirectionality in reactiv programming languages as an open issue in Section 5.
  25. 25. 関数型リアクティブプログラミング(FRP) ➤ 関数の引数がイベント ➤ 引数の値が変わる(イベントが発⽣する)と⾃動的に関数が呼ばれる ➤ 例: ➤ (draw-circle mouse-x mouse-y) ➤ mouse-x、mouse-yの値が変わるとdraw-circle関数が⾃動的に呼ばれる ➤ 関数型⾔語と関数型リアクティブプログラミングは直接関係ない ➤ 関数でリアクティブプログラミングを実現するのがFRP ➤ 関数型⾔語でなくてもFRPは実現可能 25
  26. 26. 関数型リアクティブプログラミングの種類 26 rvey on Reactive Programming Table II. Functional reactive programming (FRP) siblings Language Host language Fran [Elliott and Hudak 1997] Haskell Yampa [Hudak et al. 2003] Haskell Frapp´e [Courtney 2001] Java FrTime [Cooper and Krishnamurthi 2006] PLT Scheme (now known as Racket) NewFran [Elliott 2009] Haskell Flapjax [Meyerovich et al. 2009] JavaScript Scala.React [Maier et al. 2010] Scala AmbientTalk/R [Carreton et al. 2010] AmbientTalk posing events and switching combinators to support the dynamic reconfigura e dataflow and support higher-order dataflow.
  27. 27. 関数型でないリアクティブプログラミングの種類 27 y on Reactive Programming Table III. The cousins of reactive programming Language Host language Cells [Tilton 2008] CLOS Lamport Cells [Miller 2003] E SuperGlue [McDirmid and Hsieh 2006] Java Trellis [Eby 2008] Python Radul/Sussman Propagators [Radul and Sussman 2009] MIT/GNU Scheme Coherence [Edwards 2009] Coherence .NET Rx [Hamilton and Dyer 2010] C#.NET
  28. 28. リアクティブ プログラミングの実例
  29. 29. Fran ➤ 1997年に考案された、⼀番初めのリアクティブプログラミング⾔語 ➤ ホスト⾔語はHaskell ➤ 関数型リアクティブプログラミング ➤ リフティングは明⽰的に⾏う ➤ ただし、多くの場合でオーバーロードで対応可能 ➤ 当初はpullベースでの実装だった ➤ あとでpushにも対応 ➤ ELLIOTT, C. M. 2009. “Push-pull functional reactive programming”, In Proceedings of the 2nd ACM SIGPLAN symposium on Haskell. Haskell ʼ09. ACM, New York, NY, USA, 25–36. 29
  30. 30. Franの例(1) ➤ 摂⽒華⽒変換 ➤ tempは定義済みのbehavior 30 the need to explicitly lift operators for this particular problem dom The first implementation of Fran employs a purely pull-based However, the recent implementation of Fran [Elliott 2009] (th NewFran in this paper), combines push- and pull-based evaluation bination of these models yields the benefit of values being recompu are necessary, and almost instantaneous reactions. The temperatur ple can be realised in Fran as follows. tempConverter :: Behavior Double tempConverter = tempF where tempC = temp tempF = (tempC*1.8)+32 tempConverter is a function that returns a behaviour whose value in time is the value of the current temperature in degrees Fahrenhe there is a predefined behaviour temp whose value at any given t temperature in degrees Celsius. In order to illustrate Fran’s support for the dynamic dataflow s tempの値が変わるとtempConverterの値も⾃動的に変わる
  31. 31. Franの例(2) ➤ 円を書く関数 ➤ lbp、rbpはevent ➤ withColorは描画関数 ➤ circleは事前に定義されたbehavior 31 where tempC = temp tempF = (tempC*1.8)+32 tempConverter is a function that returns a behaviour whose value at any given point in time is the value of the current temperature in degrees Fahrenheit. We assume that there is a predefined behaviour temp whose value at any given time is the current temperature in degrees Celsius. In order to illustrate Fran’s support for the dynamic dataflow structure and high- order reactivity, we consider an example of drawing a circle on the screen and painting it red. The colour of the circle then changes to either green when the left mouse button is pressed or red when the right mouse button is pressed. This example also appears in [Elliott and Hudak 1997]. Such a program in Fran can be easily expressed as follows: drawcircle :: ImageB drawcircle = withColour colour circle where colour = stepper red (lbp -=> green .|. rbp -=> red) In the above example, circle is a predefined behaviour for a circle while lbp and rbp are events that represent left button presses and right button presses respectively. The merge operator .|. produces events when either input events have an occurrence. We use the stepper combinator to create the colour behaviour that starts with red until the first button press at which point it changes to either green or red. withColour is 左ボタンクリックなら緑に 右ボタンクリックなら⾚に 初期値
  32. 32. Flapjaxの例(1) ➤ JavaScript上でFRPを実現 ➤ pushベース ➤ 関数型リアクティブプログラミング 32 The tempConverter function implements the functionality of converting temperature from degrees Celsius to degrees Fahrenheit. We assume that there is a predefined behaviour Temperature whose value at any given point in time is the current tempera- ture. The insertValueB function inserts the values of the behaviours tempC and tempF in the DOM elements. We further illustrate Flapjax’s support for first-class behaviours and primitive com- binators using the example of drawing on a circle a screen that changes colour depend- ing on whether a left or right mouse button is pressed. The example can be expressed as follows. //draw circle at (x,y) and paint it colour function drawcircle(x, y, colour) {...}; //map button press to colour function handleMouseEvent(evt) {...}; var buttonE = extractEventE(document,"mousedown"); var colourE = buttonE.mapE(handleMouseEvent); var colourB = startsWith(colourE, "red"); var canvas = document.getElementById(’draw’); drawcircle(mouseLeftB(canvas), mouseTopB(canvas), colourB); In the above example, we use Flapjax’s combinators extractEventE and mapE to ex- tract mousedown events from the DOM and transform them into colour events. The behaviors events lifting どういう仕組かわからないけれど、colourBが変更されたり、 リドローするときに、drawcircleが呼び出される。すごい。
  33. 33. Flapjaxの例(2) ➤ http://www.flapjax-lang.org/try/index.html?edit=mouse_coords.fx ➤ マウスを動かすとHTMLが勝⼿に更新される謎技術 33 <html> <head> <title>Flapjax Demo: Where is the Mouse?</title> <link rel="stylesheet" href="/demo.css"/> </head> <body> <p>The mouse coordinates are &lt; {! mouseLeftB(document) !}, {! mouseTopB(document) !} &gt; </p> </body> </html>
  34. 34. Trellisの例 ➤ Python上で構築された、リアクティブプログラミング環境 ➤ glich回避は部分的にされているが、完全ではないらしい?(詳細は調べていない) ➤ push型のモデル ➤ 関数型じゃないリアクティブプログラミング 34 :26 E. Bainomugisha et al. class TempConverter(trellis.Component): tempC = trellis.attr(Temperature) tempF = trellis.maintain( lambda self: self.tempC * 1.8 + 32, initially = 32 ) @trellis.perform def viewGUI(self): display "Celsius: ", self.tempC display "Fahrenheit: ", self.tempF 事前に定義された変数(イベント)に関連づけ
  35. 35. .NET RXの例 ➤ 統合⾔語クエリLINQ上に構築された.NET拡張 ➤ イベントソースに対して、IObservable<T>というジェネリックインターフェースを提供 ➤ IObservable<T>は、イベントオブザーバを登録するためのメソッドSubscribeを提供 ➤ push型のモデル ➤ glichに関しては不明(No ? と論⽂に書いてある) ➤ 関数型じゃないリアクティブプログラミング 35 .NET Rx [Hamilton and Dyer 2010] is a reactive programming extension to It is built on top of LINQ [Microsoft 2007], a project that adds query fa to the .NET Framework. As in Scala.React, .NET Rx provides a generic in IObservable<T> for representing event sources. The IObservable interface prov method Subscribe that enables one to register a closure that will be executed w event occurs. In addition, .NET Rx allows event composition. New specific even be created from general events using the rich set of LINQ combinators (e.g., agg selection, joins, etc.). The propagation of events in .NET Rx is based on the push model. Consume ister interest in particular event types and then the events are pushed to them they occur. This work is still ongoing and from the available documentation it explained if the language achieves glitch freedom. The temperature conversion example can be realised in .NET Rx as follows. var temperature = new Temperature(); temperature.Subscribe( temp => { var tempC = temp.currentTemperature; var tempF = (tempC*1.8)+32; }) IObservabale<T>を実装したクラス
  36. 36. まとめ
  37. 37. まとめ ➤ リアクティブプログラミングというプログラミングパラダイムを紹介 ➤ 1997年に登場と、⾔語のモデルとしては⽐較的新しい ➤ オブジェクト指向:1967年、Simula⾔語 ➤ ジェネリックプログラミング:1989年 ➤ Musser, D. R.; Stepanov, A. A. (1989). "Generic programming". In P. Gianni. Symbolic and Algebraic Computation: International symposium ISSAC 1988. Lecture Notes in Computer Science 358. pp. 13–25. doi: 10.1007/3-540-51084-2_2. ISBN 978-3-540-51084-0 ➤ イベントを抽象化して記述できる ➤ 複雑なイベントの操作も簡単になるらしい ➤ GUIなどで⼤活躍 37
  38. 38. EOF 38

×