Typinferenz mit Produkttypen

Ich arbeite an einem Compiler für eine verkettete Sprache und möchte Unterstützung für Typinferenz hinzufügen. Ich verstehe Hindley-Milner, aber ich habe die Typentheorie im Laufe der Zeit gelernt, daher bin ich mir nicht sicher, wie ich sie anpassen soll. Ist das folgende System solide und eindeutig ableitbar?

Ein Begriff ist ein Literal, eine Zusammensetzung von Begriffen, ein Zitat eines Begriffs oder ein Primitiv.

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

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

Alle Begriffe bezeichnen Funktionen. Für zwei Funktionen $e_1$ und $e_2$ , $e_1\:e_2 = e_2 \circ e_1$ , das heißt, die Nebeneinanderstellung bezeichnet die umgekehrte Zusammensetzung. Literale bezeichnen niladische Funktionen.

Die Begriffe außer Komposition haben grundlegende Typregeln:

\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$

Insbesondere fehlen Anwendungsregeln, da es an konkatenativen Sprachen mangelt.

Ein Typ ist entweder ein Literal, eine Typvariable oder eine Funktion von Stapel zu Stapel, wobei ein Stapel als rechtsverschachteltes Tupel definiert ist. Alle Funktionen sind implizit polymorph in Bezug auf den "Rest des Stapels".

\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}$

Dies ist das erste, was verdächtig erscheint, aber ich weiß nicht genau, was daran falsch ist.

Um die Lesbarkeit zu verbessern und Klammern zu reduzieren, gehe ich davon aus, dass in Typschemata. Ich werde auch einen Großbuchstaben für eine Variable verwenden, die einen Stapel statt eines einzelnen Werts bezeichnet. $a\:b = b \times (a)$

Es gibt sechs Grundelemente. Die ersten fünf sind ziemlich harmlos. dupNimmt den höchsten Wert und erstellt zwei Kopien davon. swapÄndert die Reihenfolge der beiden obersten Werte. popverwirft den obersten Wert. quoteNimmt einen Wert und erzeugt ein Zitat (eine Funktion), das ihn zurückgibt. applyWendet ein Zitat auf den Stapel an.

\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}$

Der letzte Kombinator compose, sollte zwei Zitate nehmen und die Art ihrer Verkettung zurück, das heißt, . In der statisch typisierten VerkettungsspracheCatist der Typ vonsehr einfach. $[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)$

Dieser Typ ist jedoch zu restriktiv: Er erfordert, dass die Produktion der ersten Funktion genau mit dem Verbrauch der zweiten Funktion übereinstimmt . In Wirklichkeit muss man verschiedene Typen annehmen und sie dann vereinheitlichen. Aber wie würden Sie diesen Typ schreiben?

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$

Wenn Sie lassen einen bezeichnen Unterschied von zwei Typen, dann ich $\setminus$ denke , Sie die Art der schreiben kann composerichtig.

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))$

Dies ist immer noch relativ einfach: composenimmt eine Funktion und eine . Sein Ergebnis verbraucht oben auf dem Verbrauch von nicht erzeugt und erzeugt oben auf die Herstellung von nicht verbraucht durch . Dies gibt die Regel für die gewöhnliche Zusammensetzung. $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]}$

Ich weiß jedoch nicht, dass dieses hypothetische tatsächlich irgendetwas entspricht, und ich habe es lange genug im Kreis , sodass ich glaube, dass ich falsch bin. Könnte es ein einfacher Unterschied von Tupeln sein? $\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}$

Gibt es etwas Schreckliches daran, das ich nicht sehe, oder bin ich auf dem richtigen Weg? (Ich habe wahrscheinlich einige dieser Dinge falsch quantifiziert und würde auch Korrekturen in diesem Bereich begrüßen.)

programming-languages logic compilers type-theory type-checking Jon Purdy
quelle

Wie verwenden Sie Variablen in Ihrer Grammatik? Diese Frage soll Ihnen bei der Handhabung der "Untertypisierung" helfen, die Sie anscheinend benötigen.

jmad

@jmad: Ich bin nicht sicher, ob ich die Frage verstehe. Typvariablen sind nur dazu da, Typschemata formal zu definieren, und die Sprache selbst hat überhaupt keine Variablen, sondern nur Definitionen, die [gegenseitig] rekursiv sein können.

Jon Purdy

compose

C = D

$C=D$

twicedup compose apply[1 +] twice

ι \to ι

$\iota\to\iota$ [pop] twice

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

$\forall A b.\:f_1, f_2 : A\:b\to A$

A \neq A b

$A \neq A\:b$ Daher ist der Ausdruck nicht zulässig, obwohl er gültig sein und einen Typ haben sollte

\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

komponieren : \forall EIN B C δ . δ (\forall α . α EIN \to α B) (\forall β . β B \to β C) \to δ (\forall γ . γ EIN \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)$ scheint ausreichend allgemein zu sein. Es ist viel polymorpher als der in der Frage vorgeschlagene Typ. Hier wird die Variable über zusammenhängende Stapelstücke quantifiziert, wodurch Funktionen mit mehreren Argumenten erfasst werden.

Griechische Buchstaben werden nur aus Gründen der Übersichtlichkeit für die übrigen Stapelvariablen verwendet.

Es drückt die Einschränkungen aus, dass der Ausgabestapel des ersten Elements im Stapel mit dem Eingabestapel des zweiten Elements identisch sein muss. Variable entsprechend instanziieren $B$ Denn mit den beiden eigentlichen Argumenten wird erreicht, dass die Einschränkungen ordnungsgemäß funktionieren, anstatt eine neue Operation zu definieren, wie Sie in der Frage vorschlagen.

Type checking rank-2 types is undecidable in general, I believe, though some work has been done that gives good results in practice (for 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
quelle

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

Typinferenz mit Produkttypen

Antworten: