オンライン上での「カラー（Color）」に関する議論：非同期処理と変更依存グラフの再定義

1. 従来の「引数がカラーである」という論点

長年続いた議論において、「関数の引数に色（カラー）属性を持たせる」ことが合理的だと考える人が多かった。その典型例として Go 言語の

context.Context

• 特徴: タイムアウト管理、キャンセル、少量データの伝達を目的とする。
• 挙動: 呼び出し元で直接使われなくても、関数チェーンを通じて次の関数へ継承される設計になっている。
• 誤解のポイント: 「一度コンテキストを使用する関数が開始すれば、理論上全ての呼出関数も渡すべき」という前提から、「すべての関数のパラメータがカラーである」と結論づける議論になる。

2. なぜこの考え方は正しいのか？（反論）

もし「引数を追加するだけで済むなら」議論の必要性は薄れる。しかし、非同期処理は単なる「一つのカラー」ではない。

• 歴史的背景: 「関数」という概念から 50 年以上後になって登場した「カラー」という特性は、単純な引数の拡張とは異なる。
• 本質的な違い: 非同期処理には他の要素とは明らかに異なる特徴があり、その捉え込みを学ぶ価値がある。
• 事例の限界: 単なる例示ではなく、「変更依存グラフ形状」という基準で再定義する必要がある。

3. 新定義：変更依存グラフ形状

ある関数の属性を変更する場合、その影響がコールスタック（Call Stack）に及ぼす範囲によって「カラー」とみなすべきかどうかを判断する。

変更の影響範囲のケース

関数の変更が上位関数に波及する際、以下の 3 つのケースに分けられる：

• ケース A: 呼び出し元への変更は一切不要。
• ケース B: 直接的な親関数のみ変更が必要になる可能性がある。
• ケース C: コールスタック上の全ての関数を変更せざるを得なくなる。

グラフィック表現の比較

• [非カラー図]: 影響が呼び出し元（直接）のみ、または局所化する形状。
• [カラー図]: 変更がコールスタック最下部から頂部まで波及し、全ての上位関数が即座かつ避けられない形で影響を受ける形状。

「通常の」変更:

• 影響は呼び出し元に限定されることがほとんど。
• チェーン反応が発生しても、トップレベル関数まで伝播するケースは稀であり、本質的な差はないとみなせる。

「カラー」の変更（最悪のケース）:

• スタック最下部の変更が親関数だけでなく、コールスタック上のすべての上位関数に即座に影響を与える。
• 全ての関数がその変化に対応せねばならない。

4. 変更の隔離（Change Isolation）と現実的なコード

「実際のコード」では、変更がスタック全体を伝播することは極めて稀である。

なぜ頻繁に起こらないのか？

• カプセル化: 関数は変更を受け取り、それを内部で処理して上位関数からは見えなくする能力を持つ。
• 連鎖の断絶: コールスタック頂部（主関数）まで到達する前に、連鎖が切れることが多い。
• 構造化プログラミング: 上位関数を下位関数の詳細から隔離する技術は広く普及している。

Go

context

の具体例

Go では

context.Background()

• 一般的な実装パターン:

  // コンテキストを受け取る関数
  func MyFunc(ctx context.Context) error { ... }
  
  // 元の引数なしの関数を呼び出す際
  err := MyFunc(context.Background()) // 通常の関数から直接呼び出せる
  

• 事実: テストコードやコンテキストに関心のない呼び出し元を適応させる際、このパターンは非常に一般的。
• 結論: 「変更をスタック全体に渡さねばならない」ことは不快だが、多くの方法で軽減されており、「主関数まで到達する必要があるケース」は例外であり、認知上大きく見える稀有な事件に過ぎない。

「カラー」の変更はこのカプセル化を回避する。 スタック上の全ての上位関数が要件を満たせねばならないのが「カラー」の核心である。

5. 「カラー」の厳密な定義

依存関係の形状が特定のパターンを持つことが必須条件となる。

判断基準

注意点：非同期処理の多様性

全ての非同期処理が「カラー」を意味するわけではない。言語ごとの実装による。

• Zig の例: IO を行う関数が受け付ける

  io

  値の種類に応じて「カラー」かどうかを判断する。
• JavaScript の場合: 同期コンテキスト内で非同期アクションを実行する場合など、コストが高く機能破壊に近いケースは、「正に非同期処理をしているとは言い難い」と捉えられる。
• スペクトラム: 「カラー」の定義は線引きではなく、複雑なスペクトラム（グラデーション）として捉えるべきである。

6. 上級トピック：部分的なカラー（Partial Coloring）

Haskell などでは、「部分カラー」という概念が存在する。これは「IO カラー」といった既存のカラーに乗っかった新しい制約を作る場合である。

Haskell の

STM

モナドの例

ソフトウェアトランザショナルメモリの

STM

• 挙動:

  • readTVar

    などの関数は

    STM

    コンテキスト内からのみアクセス可能。
  • 純粋関数が

    STM

    要素を使う場合、スタック全体が

    STM

    「カラー」にリフトされる。
• カプセル化の境界:
  • トップレベルプログラムの型は

    IO ()

    であり、ここには

    STM

    は直接登場しない。

  • IO

    を除く任意の型は、主関数の下層でカプセル化されていると保証される。
• 結論: Haskell はコードの一部に対して「カラーのシェード」（部分カラー）を追加することを許可しているが、これはすべて IO 依存である。

State モナドとの比較

• State

  モナドは**「カラー」ではない**。
• 理由：状態を渡すこと自体は妨げられておらず、純粋関数同士で計算を行えるため。
• 例外: Haskell は追加のカラー（部分カラー）を作成することを許可しているが、大多数の言語ではユーザーによるカラー追加は許容されない。

7. 結論：「カラー」とは何だか？

「カラー」とは、以下の特徴を持つ変更を指す。

1. 境界の超越: 介入する呼び出しを超えて飛び出す。
2. 強制性: 関連する「カラー島」内の全関数に変更を強制する。
3. カプセル化の回避: 中間の層で変換や隔離を試みることを型システムなどが防ぐ（

   unsafe

   を除く）。

重要な区別:

• 非カラー: 変換要求としてスタックを上がっていくが、原則として上位関数からカプセル化できる。
• カラー: カプセル化が不可能であり、具体的なインスタンスで実用的な解決策がない場合でも、「カラー」とみなされる。

まとめ: コードベースの一部に対してのみ適用可能な「カラーのシェード」が存在することはあり得るが、それはあくまで例外であり、通常の変更はカプセル化できるという原則が崩れる「カラー」とは本質的に異なる。