私は実験的な言語のインタプリタを書いています。言語の主な構成要素の 3 つは、定義、ステートメント、および式です。定義にはステートメントと式を含めることができ、ステートメントには定義と式を含めることができ、1 種類の式にステートメントを含めることができます。パターン マッチングを簡単に使用できるように、ユニオン型を使用してこれらすべてを表します。理想的には、これらのコードを別のファイルに配置したいと考えていますが、OMake は循環依存の問題について不平を言っています。私の知る限り、モジュール間の循環型定義は許可されていません。
これを解決するために私が知っている唯一の方法は、3 つの型すべてを一度に定義することです。
type defn = ...
and stmt = ...
and expr = ...
これには、型のすべてのコードが同じファイルにある必要があるようです。これを回避する方法はありますか？コード内の循環定義をどのように処理しますか?
再帰的な定義は、同じファイルに表示される必要があります。定義、ステートメント、および式を別々のモジュールに分けたい場合は、再帰モジュールを使用して行うことができますが、それらは同じファイルに表示される必要があります。ファイル間の依存関係を DAG 化することは、OCaml の煩わしさの 1 つです。
これは、参照するタイプに対してタイプをパラメーター化することで簡単に解決できます。
type ('stmt, 'expr) defn = ...
type ('defn, 'expr) stmt = ...
type ('defn, 'stmt) expr = ...
この手法は「再帰的な結び目を解く」（Gordianの結び目を参照）と呼ばれ、OCamlJournalの記事で説明されています。
乾杯、ジョン・ハロップ。
よく使用される別の解決策は、インターフェイスで型を抽象化することです。インターフェースでは型が抽象的であるため、これらのインターフェースは再帰的に依存しません。実装では、型を指定できます。実装はインターフェイスのみに依存するため、再帰的でもありません。
唯一の問題は、このソリューションでは、実装の外部でこれらの型のパターン マッチングを行うことができなくなることです。
個人的には、好みの問題かもしれませんが、プログラムのすべてのタイプを 1 つのモジュールで定義するのが好きです (プログラムの読みやすさに役立つと思います)。したがって、OCaml のこの制限は、私にとって実際には問題ではありません。