ボックス化されていない型よりも上位の多態性

Hindley–Milnerに基づいて型推論を行い、デフォルトで型がボックス化されていない言語があります。主に存在型を扱うために、より高いランクのポリモーフィズムを追加したいと思います。

これらの型をチェックする方法は理解していると思いますが、コンパイルするときに何をすべきかわかりません。現在、私はC ++テンプレートのように特殊化を生成することによってポリモーフィックな定義をコンパイルし、ボックス化されていない値を処理できるようにしています。たとえば、の定義が与えられf<T>、プログラムがf<Int32>and のみを呼び出す場合、f<Char>それらの特殊化のみがコンパイルされたプログラムに表示されます。（今のところ、プログラム全体のコンパイルを想定しています。）

しかし、多態性関数を引数として渡すと、実行時に関数を選択できるため、適切な特殊化を静的に生成する方法がわかりません。ボックス化された表現を使用する以外に選択肢はありませんか？または問題を回避する方法はありますか？

私の最初の考えは、なんとかしてランクnの多型をランク1としてエンコードすることでしたが、構造論理の式は必ずしも通常の形をしているわけではないので、一般にそれが可能であるとは思いません。

私はこれについて少し考えました。主な問題は、一般に、多相型の値がどれほど大きいかわからないということです。この情報がない場合は、何らかの方法で入手する必要があります。モノモーフィゼーションは、ポリモーフィズムを特化することによってこの情報を取得します。ボクシングは、既知のサイズの表現にすべてを入れることにより、この情報を取得します。

3番目の選択肢は、この情報を種類別に追跡することです。基本的には、データサイズごとに異なる種類を導入することで、特定のサイズのすべてのタイプに対して多態性関数を定義できます。以下にそのようなシステムをスケッチします。

$$\newcommand{\bnfalt}{\;\;|\;\;} \newcommand{\rule}[2]{{\mathord{\array{#1}} \over {\mathord{#2}}}} \newcommand{\judge}[3]{{#1} \vdash {#2} : {#3}}$$ $$\begin{array}{llcl} \mbox{Kinds} & \kappa & ::= n \\ \mbox{Type constructors} & A & ::= & \forall a:\kappa.\; A \bnfalt \alpha \bnfalt A \times B \bnfalt A + B \bnfalt A \to B \\ & & | & \mathsf{ref}\;A \bnfalt \mathsf{Pad}(k) \bnfalt \mu \alpha:\kappa.\; A\\ \end{array}$$

ここでは、タイプの種類によって、メモリ内にオブジェクトを配置するのに必要な単語数がわかるという高いレベルの考え方があります。任意のサイズについて、その特定のサイズのすべてのタイプで多態性になるのは簡単です。すべてのタイプ（ポリモーフィックなタイプであっても）のサイズは既知であるため、コンパイルはCの場合より難しくありません。

分類規則はこの英語を数学に変換し、次のようになります：

$$\rule{ \alpha:n \in \Gamma} { \judge{\Gamma}{\alpha}{n} } \qquad \rule{ \judge{\Gamma, \alpha:n}{A}{m} } { \judge{\Gamma}{\forall \alpha:n.\; A}{m} }$$ $$\rule{ \judge{\Gamma}{A}{n} & \judge{\Gamma}{B}{m} } { \judge{\Gamma}{A \times B}{n + m} } \qquad \rule{ \judge{\Gamma}{A}{n} & \judge{\Gamma}{B}{n} } { \judge{\Gamma}{A + B}{n + 1} }$$ $$\rule{ \judge{\Gamma}{A}{m} & \judge{\Gamma}{B}{n} } { \judge{\Gamma}{A \to B}{1} } \qquad \rule{ \judge{\Gamma}{A}{n} } { \judge{\Gamma}{\mathsf{ref}\;A}{1} }$$ $$\rule{ } { \judge{\Gamma}{\mathsf{Pad}(k)}{k} } \qquad \rule{ \judge{\Gamma, \alpha:n}{A}{n} } { \judge{\Gamma}{\mu \alpha:n.\; A}{n} }$$

したがって、forall量指定子では、範囲を広げる種類を指定する必要があります。同様に、ペアリングはボックス化されていないペアタイプであり、メモリ内で隣にを配置するだけです（C構造体タイプのように）。Disjoint unionは、同じサイズの2つの値を取り、次に、弁別子タグの単語を追加します。関数はクロージャであり、通常、環境とコードのレコードへのポインタで表されます。A $A \times B$$A$$B$

参照は興味深いものです。ポインタは常に1語ですが、任意のサイズの値を指すことができます。これにより、プログラマー はボクシングによって任意のオブジェクトにポリモーフィズムを実装できますが、そうする必要はありません 。最後に、明示的なサイズが機能するようになったら、スペースを使用するが何もしないパディングタイプを導入すると便利です。（したがって、intと1組のintの素な結合を取得する場合は、最初のintにパディングを追加して、オブジェクトのレイアウトが均一になるようにする必要があります。）

再帰型には標準の形成規則がありますが、再帰発生は同じサイズでなければならないことに注意してください。これは、通常、それらをポインタに固定して、分類を機能させる必要があることを意味します。たとえば、リストのデータ型は次のように表すことができます

$$\mu \alpha:1.\; \mathsf{ref}\;(\mathsf{Pad}(2) + \mathsf{int} \times \alpha)$$

したがって、これは空のリスト値、または別のリンクされたリストへのポインターと整数のペアを指します。

このようなシステムの型チェックもそれほど難しくありません。私のICFP論文にあるJoshua Dunfieldのアルゴリズム、より高いランクのポリモーフィズムのための完全で簡単な双方向型チェックは、ほとんど変更なしでこのケースに適用されます。

これは、「理論的なコンピューターサイエンス」の問題よりもコンパイルの問題に近いようです。そのため、他の場所に質問することをお勧めします。

一般的なケースでは、確かに、ボックス化された表現を使用する以外に解決策はないと思います。しかし、実際には、状況の詳細に応じて、さまざまな代替オプションがあることも期待しています。

たとえば、ボックス化されていない引数の低レベルの表現は、通常、整数または類似の、浮動小数点、またはポインターなど、非常に少数の選択肢に分類できます。したがって、関数の場合f<T>、おそらく3つの異なるボックス化されていない実装を生成する必要があるだけであり、ポリモーフィックな実装を3つの関数のタプルとして表すことができるため、TをInt32にインスタンス化することは、タプルの最初の要素を選択するだけです...