Chapter 3: bind — 動的な依存グラフ

Chapter 1と2では、.map()と.link()が、一度定義されると変化しない静的な依存関係を構築する方法を見ました。

.map()はあくまで値を変換するだけなので、Timelineそのものを切り替えることはできません。この、依存関係の構造そのものを、動的に、かつ安全に（＝古い依存関係をクリーンアップしながら）切り替える課題を解決するのが.bind()です。

.bind() — 依存関係を切り替えるHOF

.bind()の本質は、.map()のように単に値を変換するのではなく、ソースTimelineの値に基づいて、次に接続すべきTimelineそのものを返す関数を受け取ることです。

これにより、依存グラフの配線が時間と共に変化する、動的なシステムを構築できます。

API定義

F#: bind: ('a -> Timeline<'b>) -> Timeline<'a> -> Timeline<'b>

TS: .bind<B>(monadf: (value: A) => Timeline<B>): Timeline<B>

引数に取る関数（monadf）が、値Aを受け取り、新しいTimeline<B>を返す点が.map()との決定的な違いです。

TimelineというFRPライブラリで bind あるいはMonadという代数構造はいったい何の役に立つのか？

我々はこの本を通じて、Monadという代数構造の抽象概念、その具体的な関数としての、bind を調べてきました。しかしFRPではこのMonadと言う代物はいったい何の役に立つのか？

実際このミステリーについてはほとんどのプログラマーは答えを持っていません。そして、既存のFRPライブラリの開発者、エコの参加者でさえそうかもしれません。彼らは明確な答えを持っていないだろうと観察されます。

そこで、今ここで一つの明確な答えを示したいと思います。

FRPライブラリのダイアモンド問題ーAtomic Update

1. ダイアモンド問題の定義

FRP（Functional Reactive Programming）におけるダイアモンド問題とは、依存関係のグラフが菱形（ダイアモンド型）になった時に発生する、グリッチ（Glitch）と非効率性に関する問題です。具体的には、あるタイムラインDがBとCという2つのタイムラインに依存し、そのBとCが共通のソースであるAに依存している場合に起こります。

      A
     / \
    B   C
     \ /
      D

この構造でAの値が更新されると、その変更はBとCの両方に伝播し、続いてBとCの更新がDに伝播します。

問題の内容：

• Aが更新されると、BとCが更新される

• しかし、BとCの更新順序が不定だと、Dが異なるタイミングで2回更新される可能性がある

• 一時的に不整合な状態でDが計算されることがある（グリッチ）

具体例：

Aの値が5から10に変更されたケースを考えます。

JavaScript

let A = 10;
let B = A + 1;    // 期待値: 11
let C = A * 2;    // 期待値: 20
let D = B + C;    // 期待値: 31

しかし、更新の伝播順序によっては、グリッチが発生します。

1. B が先に更新されると、D は B の新しい値(11)とCの古い値(10)を使って計算されてしまいます。

   D = 11 + 10 = 21 (グリッチ)

2. その後にCが更新され、DはBの新しい値(11)とCの新しい値(20)を使って再度計算されます。

   D = 11 + 20 = 31 (最終的な正しい値)

この中間状態（D=21）は、意図しない副作用（例: UIの一時的なちらつき）を引き起こす可能性があり、深刻なバグの原因となります。

---

2. 既存の多くのFRPライブラリのアプローチ

この根深い問題を解決するため、多くの既存FRPライブラリ（例えば、RxJS、Bacon.js、MobXなど）は、内部的に高度で複雑な機構を実装しています。それらは主に、更新を同期的に即時伝播させるのではなく、一度更新をキューイングし、制御された方法で実行するアプローチを取ります。

• トポロジカルソートによる更新順序の制御: 依存関係グラフを解析し、A→B、A→C、(B,C)→Dという正しい順序で更新が実行されるように、計算の実行順序を並べ替えます。

• トランザクションによる一括更新: Aの更新に起因する全ての変更（BとCの更新）を一つの「トランザクション」としてまとめます。そして、そのトランザクションが完了した後（つまりBとCの両方が更新された後）に初めて、Dの計算を一度だけ実行します。

• タイムスタンプによる整合性チェック: 各更新にタイムスタンプを付与し、Dを計算する際に、依存元（B, C）の更新が同じタイムスタンプを持つ（つまり同じイベントに由来する）ことを確認してから計算を実行します。

これらの手法は有効ですが、ライブラリの内部実装を複雑にし、開発者からは見えない挙動を生み出す原因ともなります。

Atomic update を実現している、とも表現されます。

3. Timelineライブラリのアプローチ：「そもそもDiamond問題なんて起こるほうがおかしい」という思想

Timelineライブラリは、上記のような低レベルな機構に頼るのではなく、より高次元な抽象化によって、この問題を根源から断ち切ります。その思想は、　「ダイアモンド問題が起こるような設計自体が誤りであり、より優れた設計を選択すべき」 という、極めて洗練されたものです。

概念的な純粋性：「AからDを定義する」という本質の表現

このライブラリが提示する究極の解決策は、.bind（モナド的構成）を用いることです。

TypeScript

const D = A.bind(a => {
    const b = a * 2;
    const c = a + 10;
    return Timeline(b + c);
});

このアプローチが他のライブラリや回避策的な手法よりも優れている理由は、その概念的な純粋性にあります。ダイアモンド問題における本質的な依存関係は、「Dの値は、突き詰めればAの値のみによって決定される」という事実です。BとCは、その計算過程における中間的な値に過ぎません。

bindを用いたこのコードは、その本質を極めて素直に表現しています。Aの各値aに対して、Dの新しい状態を内包したTimelineを返す、という単一の、純粋な関係性を定義しているのです。これは、しばしば副作用を伴う命令的な世界から、宣言的なデータフローの世界へと視点を引き上げる、このライブラリの思想そのものを体現しています。

単に bind ひとつだけで自然に Atomic update するMonad構造になっているのです。何ら水面下の複雑な仕組みも必要としていません。

4. 他のライブラリを寄せ付けないシンプルかつ洗練された解決策

このbindによるアプローチがもたらす利点は、多岐にわたります。

1. グリッチの構造的排除

一般的なアプローチとして、.mapでBとCを個別に定義し、それらを合成してDを生成しようとすると、ダイアモンドという「問題のある構造」が生まれてしまいます。しかし、bindを使うことで、依存グラフは根本的に変わります。

もはやそこには中間的なtimelineBもtimelineCも存在せず、菱形（ダイアモンド）構造自体が生まれません。したがって、グリッチや複数回更新という問題は構造的に発生し得ないのです。これは、発生した問題を後から解決するのではなく、問題が発生しない優れた設計を選ぶという、次元の違う解決策です。

2. 実行効率

この構造では、Aが更新されるたびにbindに渡された関数が一度だけ実行され、Dは一度だけ計算されます。これは非常に効率的です。

3. トランザクション処理の完全な不要性

さらに重要なのは、他のライブラリがグリッチを回避するために水面下で行っているトランザクション処理やスケジューリングといった、複雑で低レベルな処理が一切不要になるという点です。このライブラリは、高レベルな抽象化（モナド）を用いることで、そのような無駄な処理を必要としない、さらなる実行効率とシンプルさを実現しています。

4. 可読性

Aの値からDの値を計算するためのロジック（bとcの計算、そしてそれらの足し算）が、bindのコールバック内に全てまとまっています。これにより、コードの可読性は劇的に向上し、ロジックの保守も容易になります。

5. 結論：モナドによる「問題が起きない設計」

他の多くの解決策は、すべて「問題が起きた後の対処」です。それらは、発生してしまったグリッチを、トランザクションという名の複雑な機構で隠蔽しようとする対症療法に過ぎません。

しかし、bindは 「問題が起きない設計」 を可能にします。これこそが、関数型プログラミングの美しさそのものです。

.bindはMonad則という数学的な法則に裏打ちされており、その振る舞いは完全に予測可能です。モナドという強力な抽象化によって、開発者は副作用（この場合は中間状態の意図しない伝播）を完全に制御し、本質的な計算だけを安全に記述できるのです。

Timelineライブラリは、理論に忠実なので、自然な流れで、.mapだけでなく.bindを提供しています。これは別にわざわざ「ダイアモンド問題はこれで解決可能だ」と意図して設計したものではありません。Monadという代数構造は最初からそこにあるのです。

その根元的に理論的なライブラリ設計こそが、まさにこの「構造的にエレガントな問題解決」を開発者に自然と提供できる原動力であり、これこそが、このライブラリが他のFRPライブラリと一線を画す、設計思想の証左と言えるでしょう。

パフォーマンスへの自然な疑問

しかし、.bindに渡された関数が、ソースTimelineの更新のたびに新しいinnerTimelineを生成するという事実は、経験豊富な開発者に当然の懸念を抱かせます。『これは、不要なオブジェクトを絶えず生成し、パフォーマンスを低下させる直接的な原因になるのではないか？』と。この疑問はもっともであり、bindの強力な概念を、いかにして実用的なものにしているかを理解する上で、重要な論点です。

答え：動的なグラフを安全に実現する設計

結論から言えば、その心配は不要です。Timelineライブラリは、bindがもたらす動的なグラフ構造の切り替えを、安全かつ効率的に実行するための設計がなされています。その核心は、役割を終えたinnerTimelineを、フレームワークが一切の漏れなく、完全に自動で破棄するという点にあります。これは、bindの強力な概念を、リソースリークの恐怖なしに活用可能にするための、このライブラリの極めて重要な実装上の特徴なのです。

この動的なグラフ構造を安全に管理する仕組みは、Timelineライブラリの心臓部であるDependencyCoreと、Illusionという概念によって実現されています。次にその技術的な基盤を詳しく見ていきましょう。

DependencyCore

この動的な依存関係の切り替えは、どのようにして実現されているのでしょうか。その答えは、Timelineライブラリの心臓部である DependencyCore にあります。

DependencyCoreは、アプリケーション内に存在する全てのTimeline間の依存関係を記録・管理する、目に見えない中央管理システムです。.map()や.link()が静的な依存関係を登録するのに対し、.bind()はこのDependencyCoreをより高度に利用します。

Illusion — 時間発展する依存グラフ

.bind()がもたらす動的な依存関係の切り替えは、このライブラリの設計における、より深く、より強力な概念の現れです。それを理解するために、まずmapとbindにおける「可変性」のレベルの違いを整理しましょう。

• レベル1の可変性 (map/linkの世界): 静的な依存関係では、Timelineオブジェクトそのものは不変の存在です。唯一「可変」なのは、Nowという視点の移動に伴って更新される、内部の値 _last です。これは、ブロック宇宙における「現在の値」という、最小単位の イリュージョン（幻想） と言えます。

• レベル2の可変性 (bindの世界): .bind()を導入すると、この可変性の概念が拡張されます。もはや_lastという値だけが入れ替わるのではありません。.bind()が返すinnerTimelineオブジェクトそのものが、ソースの値に応じて、まるごと入れ替わります。つまり、ある瞬間の「真実」を定義している Timeline自体が、一時的で、入れ替え可能な存在 になるのです。

この「構造」レベルの可変性こそが、Illusionという概念の本質です。

概念的には、bindが返す結果のTimelineオブジェクト（例えばcurrentUserPostsTimeline）は、最初に一度だけ生成される不変（Immutable）な存在です。

しかし、我々の視点であるNowが時間軸に沿って動く可変な（Mutable）カーソルであるのと全く同じ理由で、そのカーソルと常に同期しているinnerTimeline（例えば"user123"の投稿Timelineや"user456"の投稿Timeline）は、可変でなければなりません。

innerTimelineが「破壊」されなければならない根本的な理由は、Nowカーソルの移動と同期して、依存グラフそのものが時間発展しており、それぞれの時間座標においてグラフの構造が異なる からです。

この、時間発展する依存グラフの「ある瞬間における状態」こそが Illusion です。そして、Nowカーソルの移動と、このIllusionの書き換え（古いものの破棄と新しいものの生成）を同期させる作業を、DependencyCoreが一括して命令的に管理しているのです。

つまりIllusionとは、_lastという 「値レベルの可変性」を、innerTimelineという「構造レベルの可変性」へと拡張した概念 なのです。そして後続の章で.using()を導入する際には、この可変性の概念がさらに「外部リソースのライフサイクル」にまで拡張されていきます。

応用ケース：動的なUI構築

ここまで、bindが持つ本質的な力（動的な依存グラフの構築）と、それを安全に支えるライブラリの実装（DependencyCoreとIllusionによる自動リソース管理）を見てきました。では、この理論と実装技術が組み合わさることで、実際のアプリケーション開発でどのような価値が生まれるのでしょうか。現代的なUI開発で頻繁に発生する、『ユーザーの選択に応じて、表示するコンポーネントを動的に切り替える』というシナリオを見ていきましょう。

現代的なアプリケーションでは、状況に応じて依存関係そのものを動的に切り替える必要性が頻繁に生じます。例えば、SNSアプリケーションで、表示するユーザーのタイムラインを切り替えるようなケースを考えてみましょう。

// Aさんのタイムライン
const alicesPosts = Timeline(["Alice's post 1", "Alice's post 2"]);

// Bさんのタイムライン
const bobsPosts = Timeline(["Bob's post 1", "Bob's post 2"]);

// 現在選択されているユーザーID
const selectedUserId = Timeline("alice");

// ここで、selectedUserIdの値に応じて、alicesPostsとbobsPostsを切り替えたい
// しかし、mapでは実現できない...
// const currentUserPosts = selectedUserId.map(id => {
//   if (id === "alice") return alicesPosts; // Timelineを返してしまう
//   else return bobsPosts;
// });

実践例：SNSタイムラインの動的切り替え

先ほどのSNSの例を、.bind()を使って実装してみましょう。

const usersData = {
    "user123": { name: "Alice", posts: Timeline(["post1", "post2"]) },
    "user456": { name: "Bob", posts: Timeline(["post3", "post4"]) }
};

const selectedUserIdTimeline = Timeline<keyof typeof usersData>("user123");

// 選択されたユーザーIDに応じて、そのユーザーの投稿Timelineに接続を切り替える
const currentUserPostsTimeline = selectedUserIdTimeline.bind(
    userId => usersData[userId].posts
);

console.log("Initial user posts:", currentUserPostsTimeline.at(Now));
// > Initial user posts: ["post1", "post2"]

// ユーザー選択を切り替える
selectedUserIdTimeline.define(Now, "user456");

console.log("Switched user posts:", currentUserPostsTimeline.at(Now));
// > Switched user posts: ["post3", "post4"]

このコード例は、bindの二つの側面を見事に示しています。

第一に、理論的な側面として、UIの状態を動的に切り替えるという複雑な要求を、極めて宣言的に記述しています。

第二に、実装的な側面として、その裏側ではDependencyCoreがIllusionの仕組みを通じて古いinnerTimelineを確実に破棄しており、開発者はリソース管理を意識する必要がありません。

このように、強力な理論とそれを支える堅牢な実装が両立して初めて、bindはその真価を発揮するのです。

Canvasデモ

https://g.co/gemini/share/cea0a51b75bd