Haskellは相互再帰的なlet-bindingsをサポートしています。これは素晴らしいことです。Haskellは相互再帰モジュールをサポートしていません。これは時々ひどいものです。GHCにはその.hs-bootメカニズムがあることは知っていますが、それはちょっとしたハックだと思います。
私の知る限り、相互再帰モジュールの透過的なサポートは比較的「単純」である必要があり、相互再帰let-bindingsとまったく同じように実行できます。個々のモジュールをコンパイル単位として使用する代わりに、強く接続されたすべてのコンポーネントを使用します。モジュール依存関係グラフのコンパイル単位としての。
ここで何かが足りませんか？Haskellがこのように相互再帰モジュールをサポートしない重要な理由はありますか？
この6年前の機能リクエストチケットには、すでに見たことがあるかもしれないかなりの量のディスカッションが含まれています。その要点は、GHCに関する限り、それは完全に単純な変更ではないということです。提起されたいくつかの特定の問題：
GHCには現在、コンパイル中にモジュールがどのように処理されるかについて多くの組み込みの仮定があり、それらの仮定を大幅に変更すると、相互再帰モジュールの透過的なサポートの利点を大幅に上回ります。
モジュールのグループをひとまとめにするということは、それらを一緒にコンパイルする必要があることを意味します。つまり、個別.hiの.oファイルを生成することで、より多くの再コンパイルと厄介さを意味します。
hs-bootファイルを使用する既存のビルドとの下位互換性。
相互再帰的なモジュールグループ内のモジュールの境界を越える相互再帰的なバインディングの可能性があります。これにより、暗黙のモジュールレベルのスコープ（デフォルト、場合によっては型クラスインスタンスなど）に関連する問題が発生します。
そしてもちろん、GHCの長年の仮定を変えるものと同様に、未知の予期しないバグの可能性。コンパイルプロセスに大幅な変更を加えなくても、現在、多くのものがモジュールごとにコンパイルされると想定されています。
多くの人がこれがサポートされることを望んでいますが、これまでのところ、上記のような厄介なコーナーケースをすべて処理する、可能な実装を作成したり、詳細で明確に指定された設計を作成したりした人は誰もいません。