Inferenza del tipo con i tipi di prodotto

Sto lavorando a un compilatore per un linguaggio concatenativo e vorrei aggiungere il supporto per l'inferenza del tipo. Capisco Hindley-Milner, ma sto imparando la teoria dei tipi mentre vado, quindi non sono sicuro di come adattarlo. Il seguente sistema è sano e decisamente inferibile?

Un termine è un letterale, una composizione di termini, una citazione di un termine o una primitiva.

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

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

Tutti i termini indicano funzioni. Per due funzioni $e_1$ ed $e_2$ , $e_1\:e_2 = e_2 \circ e_1$ , ovvero la giustapposizione indica la composizione inversa. I letterali indicano funzioni niladiche.

I termini diversi da composizione hanno regole di tipo base:

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

In particolare sono assenti le regole per l'applicazione, poiché mancano le lingue concatenative.

Un tipo è letterale, una variabile di tipo o una funzione da pile a pile, dove una pila è definita come una tupla annidata a destra. Tutte le funzioni sono implicitamente polimorfiche rispetto al "resto della pila".

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

Questa è la prima cosa che sembra sospetta, ma non so esattamente cosa ci sia di sbagliato.

Per aiutare la leggibilità e ridurre le parentesi, suppongo che negli schemi di tipo. Userò anche una lettera maiuscola per una variabile che indica uno stack, anziché un singolo valore. $a\:b = b \times (a)$

Ci sono sei primitivi. I primi cinque sono piuttosto innocui. dupprende il valore più alto e ne produce due copie. swapcambia l'ordine dei primi due valori. popscarta il valore più alto. quoteaccetta un valore e produce un preventivo (funzione) che lo restituisce. applyapplica una quotazione alla pila.

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

L'ultimo combinatore, composedovrebbe prendere due citazioni e restituire il tipo della loro concatenazione, ovvero . Nel linguaggio concatenativo tipicamente staticoCat, il tipo diè molto semplice. $[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)$

Tuttavia, questo tipo è troppo restrittivo: richiede che la produzione della prima funzione corrisponda esattamente al consumo della seconda. In realtà, devi assumere tipi distinti, quindi unificarli. Ma come scriveresti quel tipo?

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$

Se lasci che indichi una differenza di due tipi, allora penso che tu possa scrivere il tipo di correttamente. $\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))$

Questo è ancora relativamente semplice: composeprende una funzione e uno . Il suo risultato consuma cima al consumo di non prodotto da e produce cima alla produzione di non consumato da . Questo dà la regola per la composizione ordinaria. $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]}$

Tuttavia, non so che questo ipotetico corrisponda effettivamente a qualcosa, e lo sto inseguendo in circoli da abbastanza tempo che penso di aver fatto una svolta sbagliata. Potrebbe essere una semplice differenza di tuple? $\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
fonte

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)$ seems to be sufficiently general. It is much more polymorphic than the type proposed in the question. Here variable quantify over contiguous chunks of stack, which captures multi-argument functions.

Greek letters are used for the rest-of-the-stack variables for clarity only.

It expresses the constraints that the output stack of the first element on the stack needs to be the same as the input stack of the second element. Appropriately instantiating the variable $B$ for the two actually arguments is the way of getting the constraints to work properly, rather than defining a new operation, as you propose in the question.

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
fonte

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