拓海先生、今日の論文の話を噛み砕いて教えてください。部下から『深いサブタイピングを使えば表現力が上がる』と言われたのですが、何をどう変えればいいのか見えなくて困っています。
素晴らしい着眼点ですね！大丈夫、要点はシンプルです。論文は“深いサブタイピング（deep subtyping）”の効果を、プログラムを拡張することで“浅いサブタイピング（shallow subtyping）”だけで実現できる、と示しています。難しい言葉は後で一つずつ説明しますよ。
なるほど。ところで『拡張する』って、コードを書き換えるということですか。現場に大きな改修が必要だと困りますが。
良い視点です。ここでの『拡張』はeta expansion（η-expansion、η拡張）という小さなプログラム変換で、関数を明示的に引数を取る形にする操作です。要点を三つで言うと、1) 表現力（deep subtyping）を残す、2) 型検査の実装を簡単にする、3) 必要な箇所だけ変換する、です。現場改修のコストは限定的にできますよ。
これって要するに、面倒な型の比較を前もって『見かけ上』扱いやすくしておいて、後工程は単純なルールだけで済ませるということですか？
その通りです！端的に言えばフロント側で一手間かけておくとバックエンドの実装がずっと楽になるのです。しかも、その『一手間』は論理的に正しい変換ですから、挙動は変わりません。
投資対効果で言うと、どこにコストがかかって、どこで効果が出るのか知りたいですね。現場向けの説明が出来るように教えてください。
コストは主に二つ、1) どこをeta-expandするかを決めるための型情報の追加、2) 変換を挿入するコンパイラの実装です。効果は、型チェックの実装が浅いルールだけで済むため、保守性が上がりバグ源が減る点です。短期的には実装コストが出るが、中長期の運用コストを下げられますよ。
現場の開発チームは『深いサブタイピング（deep subtyping）』という言葉で混乱しがちです。要するに運用で注意すべきポイントは何ですか。
注意点は三つあります。1) どの値にeta-expansionを掛けるかを誤ると冗長なコードが増えること、2) 一部の型情報が不足していると適用できないこと、3) 自動変換のテストを十分に行うこと、です。これらは工程管理とテストで十分にコントロールできますよ。
分かりました。では私なりに言うと、フロントで型の見た目を整えておけば内部の比較ルールを簡単に保てるということで間違いないですね。自分の言葉で言うとそんな感じです。
