これが合理的な機能要求であるかどうか疑問に思っています (既に存在していて、アクセス方法がわからない場合はなおさらです)。
これが望ましい理由の例は、pipes ライブラリです。パイプは型を定義します:
data Proxy a' a b' b m r
大量のエイリアスがあり、そのうちのいくつかは次のとおりです。
type Effect = Proxy X () () X
type Producer b = Proxy X () () b
type Pipe a b = Proxy () a () b
type Consumer a = Proxy () a () X
ご想像のとおり、これは明確なエラー メッセージの最悪のシナリオです。ドキュメントを読んでいるプログラマーとして、パラメーターの少ない単純な型の観点から考えていますが、すべてのエラー メッセージは次のような 6 つのパラメーターを持つモンスター型の観点から見ています。
Couldn't match expected type ‘Proxy () Bool () b0 IO ()’
with actual type ‘Int -> Pipe Bool Integer m0 r0’
そのメッセージが次のようになると、より明確になります。
Couldn't match expected type ‘Pipe Bool Integer IO ()’
with actual type ‘Int -> Pipe Bool Integer IO ()’
副次的な質問として、GHC が b0 に置き換える特定の型 Integer を見失うのはなぜですか? 宣言された型は次のとおりです。
(Monad m)
=> Int
-> Pipe Bool Integer m r
ともかく ...
機能要求として型エイリアスのエラー報告を改善することは可能でしょうか?それとも GHC は型エラーを検出するずっと前にエイリアスを忘れてしまうのでしょうか? （GHCはエラーメッセージの「実際の型」の部分でエイリアスを覚えているように見えるため、GHCはエイリアスを追跡する必要があるように思えますが、コンパイラがどのように機能するかはわかりません。）