製品タイプとタイプ推論

私は、連結言語用のコンパイラに取り組んでおり、型推論のサポートを追加したいと考えています。Hindley–Milnerは理解していますが、型理論を学んでいるので、それをどのように適応させるかわかりません。次のシステムは健全で、決定的に推測できますか？

用語は、リテラル、用語の構成、用語の引用、またはプリミティブです。

e ::= x | e e | [e] | \dots

$e ::= x \:\big|\: e\:e \:\big|\: [e] \:\big|\: \dots$

すべての用語は関数を示します。2つの関数および場合、 $e_1$ $e_2$ 並置が逆組成を示しています。リテラルはニラディック関数を示します。 $e_1\:e_2 = e_2 \circ e_1$

構成以外の用語には、基本的なタイプルールがあります。

\frac{}{x : ι} [Lit] \frac{Γ ⊢ e : σ}{Γ ⊢ [e] : \forall α . α \to σ \times α} [Quot], α not free in Γ

$\dfrac{}{x : \iota}\text{[Lit]} \\ \dfrac{\Gamma\vdash e : \sigma}{\Gamma\vdash [e] : \forall\alpha.\:\alpha\to\sigma\times\alpha}\text{[Quot]}, \alpha \text{ not free in } \Gamma$

連結言語にはアプリケーションルールがないため、アプリケーションのルールは特にありません。

型は、リテラル、型変数、またはスタックからスタックへの関数のいずれかです。ここで、スタックは右ネストされたタプルとして定義されます。すべての関数は、「残りのスタック」に関して暗黙的にポリモーフィックです。

\begin{aligned} τ & ::= ι | α | ρ \to ρ \\ ρ & ::= () | τ \times ρ \\ σ & ::= τ | \forall α . σ \end{aligned}

$\begin{aligned} \tau & ::= \iota \:\big|\: \alpha \:\big|\: \rho\to\rho \\ \rho & ::= () \:\big|\: \tau\times\rho \\ \sigma & ::= \tau \:\big|\: \forall\alpha.\:\sigma \end{aligned}$

これが疑わしいと思われる最初のことですが、何が問題なのか正確にはわかりません。

読みやすくし、かっこを減らすために型スキームで。また、単一の値ではなく、スタックを示す変数に大文字を使用します。 $a\:b = b \times (a)$

6つのプリミティブがあります。最初の5つはかなり無害です。dup最上位の値を取り、その2つのコピーを生成します。swap上位2つの値の順序を変更します。popトップ値を破棄します。quote値を取り、それを返す引用（関数）を生成します。applyスタックに引用を適用します。

\begin{aligned} d u p & :: \forall A b . A b \to A b b \\ s w a p & :: \forall A b c . A b c \to A c b \\ p o p & :: \forall A b . A b \to A \\ q u o t e & :: \forall A b . A b \to A (\forall C . C \to C b) \\ a p p l y & :: \forall A B . A (A \to B) \to B \end{aligned}

$\begin{aligned} \mathtt{dup} & :: \forall A b.\: A\:b \to A\:b\:b \\ \mathtt{swap} & :: \forall A b c.\: A\:b\:c \to A\:c\:b \\ \mathtt{pop} & :: \forall A b.\: A\:b \to A \\ \mathtt{quote} & :: \forall A b.\: A\:b \to A\:(\forall C. C \to C\:b) \\ \mathtt{apply} & :: \forall A B.\: A\:(A \to B) \to B \\ \end{aligned}$

最後のcompose結合子、は2つの引用符を取り、それらの連結のタイプ、つまりを返す必要があり。静的に型付けされた連結言語Catでは、型は非常に簡単です。 $[e_1]\:[e_2]\:\mathtt{compose} = [e_1\:e_2]$ compose

c o m p o s e :: \forall A B C D . A (B \to C) (C \to D) \to A (B \to D)

$\mathtt{compose} :: \forall A B C D.\: A\:(B \to C)\:(C \to D) \to A\:(B \to D)$

ただし、このタイプは制限が厳しすぎます。最初の関数の生成が2番目の関数の消費と正確に一致する必要があります。実際には、異なるタイプを想定してから、それらを統一する必要があります。しかし、そのタイプをどのように書くでしょうか？

c o m p o s e :: \forall A B C D E . A (B \to C) (D \to E) \to A \dots

$\mathtt{compose} :: \forall A B C D E. A\:(B \to C)\:(D \to E) \to A \dots$

あなたが聞かせている場合意味の違いの2種類を、私は考えてあなたがの種類書くことができ、正しくを。 $\setminus$ compose

c o m p o s e :: \forall A B C D E . A (B \to C) (D \to E) \to A ((D ∖ C) B \to ((C ∖ D) E))

$\mathtt{compose} :: \forall A B C D E.\: A\:(B \to C)\:(D \to E) \to A\:((D \setminus C)\:B \to ((C \setminus D)\:E))$

これはまだ比較的簡単です。compose関数と1つの取ります。その結果、消費消費頂上によって生成されていない、及び生成の生産頂上で消費されない。これにより、通常の構成の規則が与えられます。 $f_1 : B \to C$ $f_2 : D \to E$ $B$ $f_2$ $f_1$ $D$ $f_1$ $f_2$

\frac{Γ ⊢ e_{1} : \forall A B . A \to B Γ ⊢ e_{2} : \forall C D . C \to D}{Γ ⊢ e_{1} e_{2} : ((C ∖ B) A \to ((B ∖ C) D))} [Comp]

$\dfrac{\Gamma\vdash e_1 : \forall A B.\: A \to B \quad \Gamma\vdash e_2 : \forall C D. C \to D}{\Gamma\vdash e_1 e_2 : ((C \setminus B)\:A \to ((B \setminus C)\:D))}\text{[Comp]}$

しかし、この仮想的な実際に何かに対応していることは知りません。タプルの単純な違いでしょうか？ $\setminus$

\begin{aligned} \forall A . () ∖ A & = () \\ \forall A . A ∖ () & = A \\ \forall A B C D . A B ∖ C D & = B ∖ D iff A = C \\ otherwise & = undefined \end{aligned}

$\begin{align} \forall A. () \setminus A & = () \\ \forall A. A \setminus () & = A \\ \forall A B C D. A B \setminus C D & = B \setminus D \textit{ iff } A = C \\ \text{otherwise} & = \textit{undefined} \end{align}$

Is there something horribly broken about this that I’m not seeing, or am I on something like the right track? (I’ve probably quantified some of this stuff wrongly and would appreciate fixes in that area as well.)

— Jon Purdy
ソース

How do you use variables in your grammar? This question should help you in handling the "subtyping" you seem to need.

— jmad

@jmad: I’m not sure I understand the question. Type variables are just there for the sake of formally defining type schemes, and the language itself doesn’t have variables at all, just definitions, which can be [mutually] recursive.

— Jon Purdy

Fair enough. Can you say why (perhaps with an example) the rule for compose is too restrictive? I have the impression that this is fine like this. (e.g. the restriction

C = D

$C=D$ could be handled by unification like for application in like in the λ-calculus)

— jmad

@jmad: Sure. Consider twice defined as dup compose apply, which takes a quotation and applies it twice. [1 +] twice is fine: you’re composing two functions of type

ι \to ι

$\iota\to\iota$ . But [pop] twice is not: if

\forall A b . f_{1}, f_{2} : A b \to A

$\forall A b.\:f_1, f_2 : A\:b\to A$ , the problem is that

A \neq A b

$A \neq A\:b$ , so the expression is disallowed even though it ought to be valid and have type

\forall A b . A b b \to A

$\forall A b.\:A\:b\:b\to A$ . The solution is of course to put the qualifier in the right place, but I’m mainly wondering how to actually write the type of compose without some circular definition.

— Jon Purdy

The following rank-2 type

compose : \forall A B C δ . δ (\forall α 。 α A \to α B ） （ \forall β 。 β B \to β C ） \to δ （ \forall γ 。 γ A \to γ C ）

$\text{compose}:\forall ABC\delta. \delta\ (\forall \alpha.\alpha\ A\to \alpha B)\ (\forall \beta.\beta\ B\to \beta C) \to \delta\ (\forall \gamma.\gamma\ A\to \gamma C)$ 十分に一般的なようです。質問で提案されているタイプよりもはるかに多態的です。ここで、変数はスタックの連続したチャンクを定量化し、マルチ引数関数をキャプチャします。

ギリシャ文字は、わかりやすくするために、残りのスタック変数に使用されています。

スタック上の最初の要素の出力スタックは、2番目の要素の入力スタックと同じである必要があるという制約を表します。変数を適切にインスタンス化する $B$ 実際の2つの引数は、質問で提案するように、新しい操作を定義するのではなく、制約を適切に機能させる方法です。

ランク2の型をチェックする型は、一般的に決定できませんが、実際には良い結果をもたらすいくつかの作業が行われていると思います（Haskellの場合）：

Simon L. Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields: Practical type inference for arbitrary-rank types. J. Funct. Program. 17(1): 1-82 (2007)

The type rule for composition is simply:

\frac{Γ ⊢ e_{1} : \forall α . α A \to α B Γ ⊢ e_{1} : \forall α . α B \to α C}{Γ ⊢ e_{1} e_{2} : \forall α . α A \to α C}

$\dfrac{\Gamma\vdash e_1:\forall \alpha. \alpha\ A\to \alpha\ B\qquad \Gamma\vdash e_1:\forall \alpha. \alpha\ B\to \alpha\ C} {\Gamma\vdash e_1\ e_2:\forall \alpha.\alpha\ A\to\alpha\ C}$

To get the type system to work in general, you need the following specialisation rule:

\frac{Γ ⊢ e : \forall α . α A \to α B}{Γ ⊢ e : \forall α . C A \to α C B}

$\dfrac{\Gamma\vdash e:\forall \alpha. \alpha\ A \to \alpha\ B} {\Gamma\vdash e:\forall \alpha.C\ A\to \alpha\ C\ B}$

— Dave Clarke
ソース

Thanks, this was very helpful. This type is correct for functions of a single argument, but it doesn’t support multiple arguments. For instance, dup + should have type

ι \to ι

$\iota\to\iota$ because + has type

ι ι \to ι

$\iota\:\iota\to\iota$ . But type inference in the absence of annotations is an absolute requirement, so clearly I need to go back to the drawing board. I have an idea for another approach to pursue, though, and will blog about it if it works out.

— Jon Purdy

The stack types quantify over stack fragments, so there is no problem dealing with two argument functions. I'm not sure how this applies to dup +, as that does not use compose, as you defined it above.

— Dave Clarke

Er, right, I meant [dup] [+] compose. But I read

α B

$\alpha\:B$ as

B \times α

$B\times\alpha$ ; say

B = ι \times ι

$B=\iota\times\iota$ ; then you have

(ι \times ι) \times α

$(\iota\times\iota)\times\alpha$ and not

ι \times (ι \times α)

$\iota\times(\iota\times\alpha)$ . The nesting isn’t right, unless you flip the stack around so that the top is the last (deepest nested) element.

— Jon Purdy

I may be building my stack in the wrong direction. I don't think the nesting matters, so long as the pairs building up the stack do not appear in the programming language. (I'm planning to update my answer, but need to do a little research first.)

— Dave Clarke

Yeah, nesting is pretty much an implementation detail.

— Jon Purdy