関数リアクティブプログラミングの実践

m@kotha.net
akio@tsurucapital.com

何の話？

• FRPについて
• FRP: Functional Reactive Programming; 関数リアクティブプログラミング
• FRPとは何か、何が良いのか
• Haskell用FRPライブラリeuphoriaの紹介
• Tsuru Capitalでの活用事例
• チュートリアルはない

FRPって何？

• FRP = 関数リアクティブプログラミング
• リアクティブプログラミングとは

リアクティブプログラミングって何？

• 時刻によって変化する値を使って計算する

• x = mouse_position.x
  y = mouse_position.y
  sum = x + y
  printf("(%d, %d); sum=%d", x, y, sum)

• 入力が変わるたびに再計算
• 用途: UI、シミュレーションなど

Haskell/ML上のリアクティブプログラミング

• Behavior a: 時刻によって変化する値(中身a型)
• Event a: 繰り返し発生し得るイベント(a型の値が付属)

• mousePosition :: Behavior (Int, Int)
  mouseClick :: Event ()

コンビネータ

• mapB :: (a -> b) -> Behavior a -> Behavior b

• mapE :: (a -> b) -> Event a -> Event b

• accum :: a -> Event (a -> a) -> Behavior a

• 例

  clickCount :: Behavior Int
    <- accum 0 (mapE (\() acc -> acc + 1) mouseClick)

• 他にもたくさん

もう一つの見方: 回路記述

• BehaviorやEventは単なる配線だと思う
• コンビネータは回路素子
• 

もう一つの見方: 回路記述; 設計上の意義

• プログラムを部品へと分割するのは設計の常套手段
• FRPは各部品が状態を持てるような分割を可能にする
• 

余談: OOと比べて何が良いの？

• 各部品が状態を持てるのは、mutableなオブジェクトを使うのに似ている。
• 利点:コードがずっと簡潔になる。なぜなら、
  • 状態を手で管理する必要がない
  • 便利な部品を抽象化してライブラリにできる(例は後で)
• 欠点:BehaviorとEventの枠組は一般的なメソッド呼び出しほど柔軟でない

euphoriaの紹介

注意

• FRPライブラリは、互いにかなり違う
• 表現力
• 効率

euphoriaの特徴: 高階

• Behavior (Behavior a)のような値を扱える
• switch :: Behavior (Behavior a) -> Behavior a
• GUIで特に重要(例: タブ切り替え)

euphoriaの特徴: 同期的

• 同時刻に発生したイベントは同時と認識される
• 菱形の依存関係で無駄な再計算をしない
• 

euphoriaの特徴: リークしない

euphoriaの特徴: 高度な関数

• 良く出てくるパターンを関数として収録
• withPrevE :: Event a -> Event (a, a)
• groupByE :: (a -> a -> Bool) -> Event a -> Event (Event a)

Tsuru Capitalでの利用例

問題: ログ解析

• 価格推移、注文、取引などが記録されている。
• 数GBのバイナリファイル。

• 1パスで複数の解析を行いたい。
• 元コードはiteratee使用。

iterateeとは

• ストリーム状のデータを処理するための枠組み
• 高階でないFRPをさらに制限したものとみなせる
• パイプライン処理
  
• 分岐
  
• 合流のあるネットワークは扱いにくい
• Eventのみ、Behaviorなし

問題0: 分岐と合流(0)

• ログには注文に言及する行がある
• 行には注文番号を含むのみで、注文の詳細は含まない
• 注文番号nがどういう注文かは、nが最初に使われたときに定義される
• 例:

  注文定義 注文243: 商品番号=0, 売り, 数量=3, 価格=233
  ...
  キャンセル 注文番号=243

• 解析プログラムは「注文番号->注文詳細」の対応を持っておく必要がある

問題0: 分岐と合流(1)

• 
• 「注文番号->詳細」の対応は複数の解析で共用したい
  
• iterateeによる解法: 全体を一個のノードに押し込めるしかない
  

問題1: 共用の部品

• 統計Aも統計Bも中間結果Mを使う
• 統計Aと統計Bを両方計算するとき、Mを一回しか計算したくない
• iterateeによる解法: 全体を一個のノードに押し込めるしかない
• euphoriaによる解法: Mを計算する部分を(モナディックに)メモ化するだけで良い

  m = memoized $ ...
  statA = ... m ...
  statB = ... m ...
  

euphoriaでログ解析 - まとめ

• 一枚岩の巨大ノードが必要なくなったので保守が楽になった
• 要求された統計しか計算しないので無駄が減った

他の使いみち

• GUI(GTKと連携、やや実験的)
• ネットワーク(実験的)

euphoriaの課題

並行、並列

• 現在の実装はシングルスレッド
• iterateeに負けている部分

手続き的なプログラム

• 「このEventから特定の値が出るまで読んで、次は…」のようなコードが書きにくい
• これもiterateeに負けている

push型実装

• 現在のeuphoriaはelereaを基礎にしている
• ほとんど変更がないときの処理を軽くしたい

結論

• FRPは使える
• http://github.com/tsurucapital/euphoria