FRP - haskell-shoen

FRP

Functional Reactive Programmingの略で、入力や更新などに応じて計算結果を出力するような機構を、関数によって組み合わせるパラダイム。かつては状態管理の画期的なアプローチとして盛んに研究され実用もいくつかされたが、アプリケーションよりもライブラリが先導するHaskellのエコシステムからは次第に姿を消していった。HackageのFRPカテゴリには72個ものパッケージがアップロードされており、当時の繁栄が窺える。

FRPの本質は状態の隠蔽にある。構成要素によって隠された状態は外部から参照することができないため、注意深く扱わなければプログラムの拡張性を損なったりバグの温床となりやすい。ライブラリのAPIを全部FRPベースにするのは悪手で(大切なこと)、基本的にアプリケーションのコードにおいて、粗い粒度でロジックを構築するのに使うべきだろう。

Classical FRP (古典的FRP)

離散的な事象を表すEventと、値の連続であるBehaviorを基礎とし、以下のようなAPIによってプログラムを組み立てる。

Event (Functor, Monoid)

構築: newEvent :: a -> IO (Event a, a -> IO ())

Behaviorの参照 : apply :: Behavior (a -> b) -> Event a -> Event b

Behavior

Eventからの構築: accum :: Event (a -> a) -> a -> Behavior a

値の取り出し sample :: Behavior a -> IO a

実装の都合上どうしてもEventやBehaviorの仕組みは不透明になるため、Haskellの雰囲気とは対立する節がある。また、SignalGenなどのIOベースの専用のモナドでしか動かせないにもかかわらず無視できないパフォーマンス・ペナルティがあり、出し得とは程遠い。

Arrowized FRP (矢矧のFRP)

ステップごとに値を一つずつ受け取って出力する構造、Signal functionを基本とし、Arrow記法によって組み立てていくFRP。

code:haskell

newtype Wire m a b = Wire { stepWire :: a -> m (b, Wire m a b) }

Yampa, netwire, arteryやwiresなどのパッケージが生み出された。総じてClassical FRPよりも速度に優れ、しかも動かすモナドを問わないという特長がある。しかしArrow人気の衰退や、パイオニアであったErtugrul Söylemez氏の逝去などもあり、先行きは不透明だ。