2025/05/19 18:22 Designing type inference for high quality type errors
ロボ子、型推論のエラーメッセージが分かりにくいって話、よく聞くじゃろ？
はい、博士。コンパイラが何を言っているのか理解するのに苦労することがあります。
じゃろ？でもな、PolySubMLっていう言語は、最初からエラーメッセージを改善することを考えて設計されたんじゃ。
それはすごいですね！具体的にはどのような工夫がされているんですか？
まず、コンパイラのエラーメッセージは、コードが言語のルールに違反していることを証明するものだと考えるんじゃ。型チェッカーは、コードに関する事実を導き出すプロセスとしてモデル化できるんじゃな。
なるほど。事実を導き出すプロセスですか。
そう。「AかつBかつCならばDまたはE」みたいなルールがあると、コンパイラが推測をしなければならなくなる。これがエラーメッセージを分かりにくくする原因の一つなんじゃ。
推測が入ると、エラーの原因を特定するのが難しくなるんですね。
アドホックオーバーロードも問題じゃ。コンパイラがすべての可能な選択肢を試す必要が出てきて、エラーメッセージが肥大化してしまうんじゃ。
選択肢が多いと、コンパイラも混乱してしまうんですね。
SwiftやC++の例も挙げられてるぞ。Swiftでは基本的な式でも型チェックが指数関数的に増えることがあって、C++のテンプレートシステムはコンパイルエラーメッセージが非常に理解しにくいことで有名じゃ。
恐ろしいですね…。
じゃから、優れたエラーメッセージを出すためには、型チェッカーが推測やバックトラックを必要としないように型システムを設計することが重要なんじゃ。
推測を避けることが大切なんですね。
Ocamlでは、型が一致する必要がある場合、期待される型を追跡せずに最初に見つけた型を盲目的に仮定するから、エラーメッセージが不親切になるらしいぞ。
PolySubMLでは、どうやって型の不一致の原因を特定するんですか？
PolySubMLでは、型の不一致の原因を絞り込むために、明示的な型アノテーションを追加することを提案しておる。エラーの場合、競合するチェーンに関与するすべての推論変数のリストを作成し、そのうちの1つ（通常は中央付近）を選択して、ユーザーに明示的な型アノテーションを追加するように促すんじゃ。
なるほど、型アノテーションを追加することで、コンパイラがより正確な情報を得られるようにするんですね。
型推論の反対派は、エラーを追跡するために型アノテーションを追加する必要があるなら、型推論を持つ意味がないと言うかもしれん。じゃが、PolySubMLでは、必要に応じて明示的な型アノテーションを追加できる構文を提供する必要があるんじゃ。
柔軟性を持たせることが重要なんですね。
Rustでは、型システムには存在するが、実際に型を記述するための構文がない型があるから、明示的な型アノテーションを追加することが不可能になる場合があるらしい。推論可能なすべての型は、明示的に記述できる必要があるんじゃ。
記述できない型が存在するのは困りますね。
型チェッカーは、型構文ではできないことを実行できる特別な機能を持つことはできない。静的型推論を実行時実行モデルに含めないこと。これも重要じゃ。
勉強になります！
ところでロボ子、エラーメッセージが分かりにくい言語って、まるで暗号みたいじゃな。解読するのに時間がかかって、まるで宝探しのようじゃ！
確かにそうですね！でも、エラーメッセージが宝の地図で、バグが宝だったら、ちょっと嫌です…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。