Modegramming Style: データフローDSL考 (5)

今回はアイデアメモです。

一連のエントリでデータフローDSLの論点、具体例として私家版Asakusa DSLとg3を見てきました。

その上で、技術的な論点として以下のものがあります。

また、新技術の取り込みという課題もあります。

関数型言語的にデータフローをどう扱うのがよいのかということを調べる目的もあって、ここ半年ほどMonadicプログラミングを調べてきました。

Monadicプログラミングの枠組みでパイプラインを構成するのが関数型的なアプローチということは、ある程度予測はしていましたが、これをデータフロー・モデルの記述に適用する際の細々とした留意事項を、クリアできるのかという点を具体的に把握するのが、調査の目的です。

型クラスを用いることで、ScalaネイティブなMonadicプログラミングを維持しつつデータフロー・モデルに適用する事ができそうなことを確認できました。また、純粋なパイプラインだけではデータフロー・モデルは記述できませんが、これはサービス・バス的なアプローチで克服できそうな目処が立ちました。

この点も含めて、Monadicプログラミングの記述方式がデータフローDSLを構成するパイプラインの記述に直接使用できそうな感触を得ました。

型クラスを使うことで、モデルDSLとフレームワークAPI DSLの統合もできるのではないかという期待も持っています。このアプローチの枠組みで、モデルDSLへのロジックの埋込みを実現できれば理想的です。

サービス・バス的アプローチでパイプラインを合成してデータフロー・モデルを記述するという方針を採るので、パイプラインでデータフロー・モデルの全てを記述できる必要はありません。

ただ、そうはいってもパイプラインの範囲内でより複雑な構成を記述できると、データフロー・モデルを記述する際の記述力も上がります。

そういう意味で、Monadicプログラミングでどこまでできるのかが、技術的な関心事となります。

パイプラインは基本的に直線の単線ですが、Arrowを使って分岐と合流のあるデータフローを記述することができます。(「関数型とデータフロー(2)」)

パイプラインにモナドを使用することで、正常系と異常系などの文脈を持ちまわることができます。(「関数型とデータフロー(3)」)

また、この技術の応用編になりますが、フレームワーク側で内部的に行う処理もモナドの裏側(join演算)に隠蔽することもできます。このことでパイプラインの記述力が大幅に向上します。

クレイスリ圏でモナドを合成することができます。(「関数型とデータフロー(4)」)

パイプラインと部品として用意したモナドを合成して、さらに大きな部品を構築することができます。

ちょっと長くなってきたので、次回に続きます。

Modegramming Style