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

1. リアクティブ
プログラミング
情報通信研究機構
⾼野 祐輝

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. リアクティブプログラミング
➤ イベントを扱うためのプログラミングモデル
➤ 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. コールバックベースなプログラミングの問題点
➤ 多くの独⽴したコード⽚が同じデータを操作する
➤ 実⾏順が予測不可能
➤ コールバック関数は返り値を持たないため、アプリケーションの状態に副作⽤を及ぼす必要がある（グ
ローバル変数）
➤ ある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. 最近の流れ
➤ リアクティブプログラミングを利⽤したライブラリが登場してきた
➤ FacebookのReact.js
➤ .NETの.NET RX
➤ RxJS
➤ Frapjax
➤ RxSwift
5

6. リアクティブ
プログラミングと
その特徴

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. Behaviorsの評価戦略
➤ 遅延評価
➤ Haskellのリアクティブプログラミング（Fran、Yampa）など
➤ 必要になった時に計算が⾏われるので無駄がない
➤ 正格評価
➤ 正格評価する⾔語も多い
➤ 無駄な計算を省くためサンプリングされる場合もある
8

9. Behaviorsの評価モデル、pullとpush（１）
➤ 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. Behaviorsの評価モデル、pullとpush（２）
➤ 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. Behaviorsの評価モデル、pullとpush（３）
➤ 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. グリッチとその対策（１）
➤ グリッチとは
➤ パルス的に起きる電気的ノイズ
➤ 接触不良
➤ 電気素⼦の劣化などが原因
➤ 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. グリッチとその対策（２）
➤ グリッチの例
➤ 次のようなリアクティブプログラミングを考えてみる
➤ 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
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. グリッチとその対策（４）
➤ 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

17. リフティングとその戦略（２）
➤ リフティングの定義
➤
➤ あるタイムステップ 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. リフティングとその戦略（３）
➤ 静的型付け⾔語に対する適⽤
➤ 静的型付けなので、関数を直接変換することは出来ない
➤ プログラマがリフト操作を⾏う必要がある
➤ ⼀般的には⾔語の提供するオーバーロードの機能を⽤いて、なるべく簡単に出来るような⼯
夫がされている
➤ 動的型付け⾔語に対する適⽤
➤ 関数については、Behaviorsも普通に引数として受け取れる
➤ ⾔語内部で暗黙的に処理される
➤ プリミティブな演算については、演算⼦オーバーロードや、コード⽣成時に⼯夫が必要
18

19. リフティングとその戦略（４）
➤ 暗黙的リフティング
➤
➤ 動的型付け⾔語で⽤いられる⼿法
➤ 明⽰的リフティング
➤
➤ 静的型付け⾔語で⽤いられる⼿法
➤ オーバーロードなどで対応している場合もこちらに分類
➤ ⼿動リフティング
➤
➤ ⾔語レベルでのサポート無しの場合は、⼿動で現在の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. 多⽅向性
➤ イベントの伝達⽅向が、⼀⽅向か双⽅向か
➤ 例：摂⽒華⽒変換
➤ F = C ＊ 1.8 ＋ 32
➤ Cが変化するとFの値が変化（ここまで⼀⽅向）
➤ 上の等式は次のように変換できる
➤ C = (F ー 32) / 1.8
➤ Fが変化するとCも変化すると双⽅向
➤ 制約プログラミングと似ている
20

21. 分散リアクティブプログラミング
➤ 分散環境でのリアクティブプログラミングは達成できるか？
➤ 問題点
➤ ⼀貫性の保証ができるのか？
➤ グリッチの解決が更に難しく
➤ グローバルクロック無し
➤ パケットロス
➤ レイテンシ
21

22. リアクティブ
プログラミングの種類

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
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. 関数型リアクティブプログラミング（FRP）
➤ 関数の引数がイベント
➤ 引数の値が変わる（イベントが発⽣する）と⾃動的に関数が呼ばれる
➤ 例：
➤ (draw-circle mouse-x mouse-y)
➤ mouse-x、mouse-yの値が変わるとdraw-circle関数が⾃動的に呼ばれる
➤ 関数型⾔語と関数型リアクティブプログラミングは直接関係ない
➤ 関数でリアクティブプログラミングを実現するのがFRP
➤ 関数型⾔語でなくてもFRPは実現可能
25

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
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. リアクティブ
プログラミングの実例

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. Franの例（１）
➤ 摂⽒華⽒変換
➤ 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. Franの例（２）
➤ 円を書く関数
➤ 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. Flapjaxの例（１）
➤ 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. Flapjaxの例（２）
➤ 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. 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. .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. まとめ

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. EOF
38