Inférence de type avec les types de produits

Je travaille sur un compilateur pour un langage concaténatif et je voudrais ajouter un support d'inférence de type. Je comprends Hindley – Milner, mais j'ai appris la théorie des types au fur et à mesure, donc je ne sais pas comment l'adapter. Le système suivant est-il solide et inférable?

Un terme est un littéral, une composition de termes, une citation d'un terme ou une primitive.

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

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

Tous les termes désignent des fonctions. Pour deux fonctions et , , c'est-à-dire que la juxtaposition désigne la composition inverse. Les littéraux désignent les fonctions niladiques. $e_1$ $e_2$ $e_1\:e_2 = e_2 \circ e_1$

Les termes autres que composition ont des règles de type de base:

\frac{}{X : ι} [Lit] \frac{Γ ⊢ e : σ}{Γ ⊢ [e] : \forall α . α \to σ \times α} [Quot], α pas libre dans Γ

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

Les règles d'application sont particulièrement absentes, car les langues concaténatives en sont dépourvues.

Un type est soit un littéral, une variable de type, soit une fonction de piles en piles, où une pile est définie comme un tuple imbriqué à droite. Toutes les fonctions sont implicitement polymorphes par rapport au «reste de la pile».

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

C'est la première chose qui semble suspecte, mais je ne sais pas exactement ce qui ne va pas.

Pour faciliter la lisibilité et réduire les parenthèses, je suppose que dans les schémas de types. Je vais également utiliser une lettre majuscule pour une variable désignant une pile, plutôt qu'une seule valeur. $a\:b = b \times (a)$

Il existe six primitives. Les cinq premiers sont assez inoffensifs. dupprend la valeur la plus élevée et en produit deux copies. swapchange l'ordre des deux premières valeurs. popignore la valeur supérieure. quoteprend une valeur et produit une citation (fonction) qui la renvoie. applyapplique un devis à la pile.

\begin{aligned} ré u p & :: \forall UNE b . UNE b \to UNE b b \\ s w une p & :: \forall UNE b c . UNE b c \to UNE c b \\ p o p & :: \forall UNE b . UNE b \to UNE \\ q u o t e & :: \forall UNE b . UNE b \to UNE (\forall C . C \to C b) \\ une p p l y & :: \forall UNE B . UNE (UNE \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}$

Le dernier combinateur compose,, doit prendre deux citations et retourner le type de leur concaténation, c'est-à-dire . Dans le langage concaténatif de type statique Cat , le type de est très simple. $[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)$

Cependant, ce type est trop restrictif: il nécessite que la production de la première fonction corresponde exactement à la consommation de la seconde. En réalité, vous devez assumer des types distincts, puis les unifier. Mais comment écririez-vous ce type?

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$

Si vous laissez dénoter une différence de deux types, alors je pense que vous pouvez écrire le type de correctement. $\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))$

Ceci est encore relativement simple: composeprend une fonction et une . Son résultat consomme au sommet de la consommation de non produite par , et produit au sommet de la production de non consommée par . Cela donne la règle de la composition ordinaire. $f_1 : B \to C$ $f_2 : D \to E$ $B$ $f_2$ $f_1$ $D$ $f_1$ $f_2$

\frac{Γ ⊢ e_{1} : \forall UNE B . UNE \to B Γ ⊢ e_{2} : \forall C ré . C \to ré}{Γ ⊢ e_{1} e_{2} : ((C ∖ B) UNE \to ((B ∖ C) ré))} [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]}$

Cependant, je ne sais pas si cet hypothétique correspond en fait à quelque chose, et je le poursuis en rond depuis assez longtemps pour que je pense avoir pris un mauvais virage. Serait-ce une simple différence de tuples? $\setminus$

\begin{aligned} \forall UNE . () ∖ UNE & = () \\ \forall UNE . UNE ∖ () & = UNE \\ \forall UNE B C ré . UNE B ∖ C ré & = B ∖ ré ssi UNE = C \\ autrement & = indéfini \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}$

Y a-t-il quelque chose d'horriblement cassé que je ne vois pas, ou suis-je sur quelque chose comme la bonne voie? (J'ai probablement quantifié à tort certaines de ces choses et j'apprécierais également les correctifs dans ce domaine.)

programming-languages logic compilers type-theory type-checking Jon Purdy
la source

Comment utilisez-vous les variables dans votre grammaire? Cette question devrait vous aider à gérer le "sous-typage" dont vous semblez avoir besoin.

jmad

@jmad: Je ne suis pas sûr de comprendre la question. Les variables de type sont juste là pour définir formellement des schémas de types, et le langage lui-même n'a pas du tout de variables, juste des définitions, qui peuvent être [mutuellement] récursives.

Jon Purdy

C'est suffisant. Pouvez-vous dire pourquoi (peut-être avec un exemple) la règle pour composeest trop restrictive? J'ai l'impression que c'est bien comme ça. (par exemple la restriction pourrait être gérée par unification comme pour une application similaire dans le λ-calcul)

C = D

$C=D$

jmad

@jmad: Bien sûr. Considérez twicedéfini comme dup compose apply, qui prend une citation et l'applique deux fois. [1 +] twicec'est bien: vous composez deux fonctions de type . Mais ce n'est pas le cas: si , le problème est que , donc l'expression est interdite même si elle doit être valide et avoir taper . La solution est bien sûr de mettre le qualificatif au bon endroit, mais je me demande principalement comment écrire réellement le type de sans définition circulaire.

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

\forall A b . A b b \to A

$\forall A b.\:A\:b\:b\to A$ compose

Jon Purdy

Le type de rang 2 suivant semble être suffisamment général. Il est beaucoup plus polymorphe que le type proposé dans la question. Ici, la quantification variable sur des morceaux contigus de pile, qui capture les fonctions multi-arguments.

composer : \forall UNE B C δ . δ (\forall α . α UNE \to α B) (\forall β . β B \to β C) \to δ (\forall γ . γ UNE \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)$

Les lettres grecques sont utilisées pour les autres variables de la pile à des fins de clarté uniquement.

Il exprime les contraintes que la pile de sortie du premier élément de la pile doit être la même que la pile d'entrée du deuxième élément. Instancier de manière appropriée la variable pour les deux arguments est le moyen de faire fonctionner correctement les contraintes, plutôt que de définir une nouvelle opération, comme vous le proposez dans la question. $B$

La vérification de type des types de rang 2 est indécidable en général, je pense, bien qu'un travail ait été fait qui donne de bons résultats dans la pratique (pour Haskell):

Simon L. Peyton Jones, Dimitrios Vytiniotis, Stephanie Weirich, Mark Shields: inférence de type pratique pour les types de rang arbitraire. J. Funct. Programme. 17 (1): 1-82 (2007)

La règle de type pour la composition est simplement:

\frac{Γ ⊢ e_{1} : \forall α . α UNE \to α B Γ ⊢ e_{1} : \forall α . α B \to α C}{Γ ⊢ e_{1} e_{2} : \forall α . α UNE \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}$

Pour que le système de typage fonctionne en général, vous avez besoin de la règle de spécialisation suivante:

\frac{Γ ⊢ e : \forall α . α UNE \to α B}{Γ ⊢ e : \forall α . C UNE \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
la source

Merci, ceci était vraiment utile. Ce type est correct pour les fonctions d'un seul argument, mais il ne prend pas en charge plusieurs arguments. Par exemple, dup +devrait avoir le type car a le type . Mais l'inférence de type en l'absence d'annotations est une exigence absolue, donc je dois clairement revenir à la planche à dessin. J'ai une idée pour une autre approche à poursuivre, cependant, et bloguerai à ce sujet si cela fonctionne.

ι \to ι

$\iota\to\iota$ +

ι ι \to ι

$\iota\:\iota\to\iota$

Jon Purdy

Les types de pile quantifient sur des fragments de pile, il n'y a donc aucun problème à gérer deux fonctions d'argument. Je ne sais pas comment cela s'applique dup +, car cela n'utilise pas la composition, comme vous l'avez défini ci-dessus.

Dave Clarke

Euh, c'est vrai, je voulais dire [dup] [+] compose. Mais j'ai lu comme ; dites ; alors vous avez et non . L'imbrication n'est pas correcte, sauf si vous retournez la pile pour que le haut soit le dernier élément (le plus profond imbriqué).

α B

$\alpha\:B$

B \times α

$B\times\alpha$

B = ι \times ι

$B=\iota\times\iota$

(ι \times ι) \times α

$(\iota\times\iota)\times\alpha$

ι \times (ι \times α)

$\iota\times(\iota\times\alpha)$

Jon Purdy

Je construis peut-être ma pile dans la mauvaise direction. Je ne pense pas que l'imbrication importe, tant que les paires qui constituent la pile n'apparaissent pas dans le langage de programmation. (Je prévois de mettre à jour ma réponse, mais je dois d'abord faire un peu de recherche.)

Dave Clarke

Oui, l'imbrication est à peu près un détail d'implémentation.

Jon Purdy

Inférence de type avec les types de produits

Réponses: