Haskell スタイルの型クラスと ML スタイルのモジュールが、インターフェースを指定するための異なるメカニズムを提供することはよく知られています。それらは (おそらく) 同等の能力を持っていますが、実際にはそれぞれに利点と欠点があります。
私は言語機能に関しては少し包摂主義者なので、私の質問は次のとおりです。Haskell に ML スタイルのモジュールを追加する際の主な理論上の問題は何ですか? 次の行に沿った回答に興味があります。
ML スタイルのモジュールとの相互作用が不十分な既存の型システム機能はどれですか? (不十分な相互作用の例は、fandeps が技術的に関連付けられた型と同等であるにもかかわらず、GADT と関数の依存関係です!)
ML スタイルのモジュールをコンパイルするために、コンパイラ側であきらめなければならないことは何ですか?
ML スタイル モジュールは型推論とどのように相互作用しますか?
関連読書:
比較を行う主な場所は、
ML モジュールと Haskell 型クラス: 建設的な比較. Stefan Wehr と Manuel MT Chakravarty。The Sixth ASIAN Symposium on Programming Languages and Systems - APLAS 2008、Springer-Verlag、LNCS、2008 の議事録。
モジュラー タイプ クラス。Derek Dreyer、Robert Harper、Manuel MT Chakravarty。第 34 回年次 ACM SIGPLAN - プログラミング言語の原則に関する SIGACT シンポジウムの議事録、ACM Press、2007 年。
Haskell 、Mark Shields、Simon Peyton Jonesのファースト クラス モジュール。オブジェクト指向言語の基礎に関する第 9 回国際会議 (FOOL 9)、オレゴン州ポートランドに提出。20ページ。2001 年 10 月。
私は実際には理論的な問題を認識していません-少なくとも、具体的な提案が行われました(そしてプロトタイプで実装されました)-Shields and PJ paperには多くの詳細があります. ただし、実装の負担は簡単ではありません。
理論上大きな問題はないと思います。アプリカティブ ファンクターを使用するかどうかを決定する必要があります。Applicative はおそらく Haskell スタイルに近いものです。しかし、ML スタイルのモジュールを Haskell に追加しようとする試みはグロテスクになると思います。モジュールとクラスが重複しているためです。多くのことを行うには2つの方法があります。
Simon PJ は、ML スタイルのモジュールは消費電力とコストの比率が低く、実装が難しいと主張しています。POPL 2003の SPJ のスライドを参照してください(最後に向けて)。彼はまた、より優れた電力/コスト比を持つ設計を求めていますが、私はそのような提案を知りません.