Les transparents du cours - PPS

Compilation Avancée 

Cours 3 : Typage 

Yann Régis-Gianas 

yrg@pps.jussieu.fr 

PPS - Université Denis Diderot – Paris 7 

21 octobre 2009

Références 

◮ Types and Programming Languages 

Benjamin C. Pierce 

◮ Advanced Topics In Types And Programming Languages 

sous la direction de Benjamin C. Pierce.

Un type, vous dites ? 

◮ Un type spécifie la forme du résultat d’un calcul avant que celui-ci n’ait lieu. 

◮ Il représente une propriété statique du calcul, c’est-à-dire un invariant. 

◮ En première approximation, on peut dire qu’une expression est bien typée 

si elle promet de faire “bon usage” de l’évaluation de ses sous-expressions.

Quelques expressions plus ou moins bien typées 

◮ Si e et f s’évaluent comme des entiers, “e + f” est bien typée. 

◮ Si e s’évalue comme un entier, alors “e = "foo"” est mal typée. 

◮ Si e s’évalue en un flottant, “sqrt e” est bien typée . . . 

(mais si e s’évalue en un flottant négatif, alors le programme explose ! ?) 

⇒ Qu’entend-on par “faire bon usage” ?

Sûreté d’un langage de programmation 

◮ Soit la relation 

e −→ e ′ 

qui signifie que l’expression e s’évalue en un pas vers l’expression e ′ . 

◮ Par exemple, pour les expressions arithmétiques : 

◮ Certaines expressions sont bloquées : 

1 + 2 + 3 −→ 3 + 3 −→ 6 

1 + ”foo” −→ 

◮ Un interprète ou un compilateur a un comportement spécifié uniquement sur 

les termes non bloquants. 

◮ Éviter les configurations bloquantes, c’est garantir la sûreté de l’exécution.

Définition formelle d’un système de typage 

◮ On écrit “E ⊢ e : T ” avec : 

◮ E un environnement de typage (une fonction des identifiants vers les types). 

◮ e une expression du langage de programmation. 

◮ T un type. 

pour exprimé le jugement “être bien typé”. 

◮ On définit ce jugement à l’aide d’un ensemble fini de règles de la forme : 

E ⊢ e : int E ⊢ f : int 

E ⊢ e + f : int 

◮ Un système de type est dirigé par la syntaxe si il n’existe qu’une et une seule 

règle de typage traitant chaque construction syntaxique du langage.

À prouver pour chaque langage de programmation ! 

◮ Si E ⊢ e : T alors l’évaluation de e ne peut pas bloquer. 

◮ Se prouve à l’aide de deux propriétés : 

◮ Si E ⊢ e : T et e −→ e ′ alors E ⊢ e ′ : T . 

◮ Si E ⊢ e : T alors 

◮ soit e est le résultat du calcul (une valeur) 

◮ soit e peut s’évaluer.

À prouver pour chaque langage de programmation ! 

◮ Si E ⊢ e : T alors l’évaluation de e ne peut pas bloquer. 

◮ Se prouve à l’aide de deux propriétés : 

◮ Si E ⊢ e : T et e −→ e ′ alors E ⊢ e ′ : T . 

◮ Si E ⊢ e : T alors 

◮ soit e est le résultat du calcul (une valeur) 

◮ soit e peut s’évaluer.

Une frontière bien connue 

◮ On ne peut pas décider toute propriété statiquement.

La tension 

◮ Que faire de la racine carrée ? 

Généralité et Richesse des programmes 

versus 

Précision du typage 

◮ Ne pas l’inclure dans le langage de programmation, elle est trop dangereuse ! 

◮ Se donner un type pour les flottants positifs. 

◮ Lancer une exception au moment de l’exécution. 

◮ “fun x ⇒ x” admet les types : 

◮ int → int 

◮ bool → bool 

◮ Lequel choisir ? Doit-on choisir ? 

◮ Si “1 + 1.5” et “1 + 1” sont des expressions bien typées, alors quelles 

sémantiques et quels types leur donner ?

Le typage dans un compilateur 

Ltypé L1 nontypé L2 nontypé L3 Typage T2 T3 

nontypé 

◮ Traditionnellement, le typage est une des premières phases des compilateurs. 

◮ Dans ce cadre, il sert à vérifier une condition de bonne formation sur laquelle 

le compilateur s’appuie aveuglement par la suite. 

⇒ Qu’arrive-t-il si une phase de compilation est incorrecte ?

Le typage dans un compilateur 

Ltypé L1 typé L2 typé L3 Typage T2 T3 

typé 

◮ Traditionnellement, le typage est une des premières phases des compilateurs. 

◮ Dans ce cadre, il sert à vérifier une condition de bonne formation sur laquelle 

le compilateur s’appuie aveuglement par la suite. 

⇒ Qu’arrive-t-il si une phase de compilation est incorrecte ? 

⇒ Il est plus sûr d’implanter des transformations préservant le bon typage. On 

élimine ainsi de nombreuses erreurs.

Un système de type pour Hamlet 

e ::= Expression 

| x, f , . . . Variable 

| 0, 1, . . . , Entier 

| e e Application 

| fun x ⇒ e Fonction 

| fix x. e Point fixe 

τ ::= Type 

| int Entiers 

| τ → τ Fonctions 

Γ ::= Environnement de typage 

| • Environnement vide 

| Γ; (x : τ) Liaison

Un système de types pour Hamlet 

(x : τ) ∈ Γ 

Γ ⊢ x : τ Γ ⊢ i : int 

Γ; (x : τ1) ⊢ e : τ2 

Γ ⊢ fun x ⇒ e : τ1 → τ2 

i ∈ N 

Γ ⊢ e1 : τ1 → τ2 Γ ⊢ e2 : τ1 

Γ ⊢ e1 e2 : τ2 

Γ; (x : τ1 → τ2) ⊢ e : τ1 → τ2 

Γ ⊢ fix x. e : τ1 → τ2

Algorithme de typage 

◮ Existe-t-il un algorithme réalisant cette spécification ?


◮ Existe-t-il un algorithme réalisant cette spécification ? 

⇒ Et si on modifie la syntaxe de la façon suivante ? 


| . . . 

| fun (x : τ) ⇒ e Fonction 

| fix (x : τ). e Point fixe 

| . . .



◮ On peut être plus souple en n’exigeant des annotations 

seulement lorsque le contexte local n’est pas suffisamment 

informatif. 

⇒ On obtient alors une forme d’inférence de type partielle. 

(x : τ) ∈ Γ 

Γ ⊢ x ⇑ τ Γ ⊢ i ⇑ int 

Γ ⊢ e1 ⇑ τ1 → τ2 Γ ⊢ e2 ⇓ τ1 

Γ ⊢ e1 e2 ⇑ τ2 

Γ; (x : τ1 → τ2) ⊢ e ⇓ τ1 → τ2 

Γ ⊢ fix x. e ⇓ τ1 → τ2 

i ∈ N 

Γ; (x : τ1) ⊢ e ⇓ τ2 

Γ ⊢ fun x ⇒ e ⇓ τ1 → τ2 

Γ ⊢ e ⇑ τ 

Γ ⊢ e ⇓ τ 

Γ ⊢ e ⇓ τ 

Γ ⊢ (e : τ) ⇑ τ



⇒ En absence de toute annotation, un moteur complet 

d’inférence des types est nécessaire (c’est le sujet de la seconde 

partie de ce cours).

Effacement des types 

◮ Dans le cadre d’une compilation “classique” (non typée), on efface les 

annotations de types une fois que le bon typage du programme a été vérifié. 

◮ Pour un compilateur préservant les types, on doit traduire à la fois les 

programmes et leurs types, ce qui peut compliquer les traduction (mais 

fournit des garanties sur leurs corrections).

Un système de type pour Clovis 


| x, f , . . . Variable 

| lookup x Extraction dans l’environnement 

| 0, 1, . . . , Entier 

| let x = e in e Définition locale 

| apply e e Application 

| closure{x = e|x ⊲ e} Construction de fermeture 

| fix x. e Point fixe 

v ::= Valeurs 

| 0, 1, . . . , Entier 

| closure{ρ|x ⊲ e} Fermeture 

◮ Le système de type de Hamlet s’applique immédiatement. 

⇒ Fournit-il les mêmes garanties en termes de sûreté de l’exécution ?

Exemple problématique 

◮ Est-ce que le programme suivant est bien typé ? 

◮ Est-ce qu’il s’exécute sans erreur ? 

apply (closure{y = 0|x ⊲ y + 1}) 1

Une algèbre de type pour Clovis 

τ ::= Type 

| int Entiers 

| ε (τ) Type construit 

ε ∈ {→, local, inenv} 



| Γ; (x : τ) Liaison 

◮ local et inenv sont des constructeurs de type d’arité 1 et “→” est d’arité 2. 

◮ On continue à noter l’application de “→” de manière infixe.

Un système de type pour Clovis 

(x : local (τ)) ∈ Γ 

∀i, Γ ⊢ ei : τi 

Γ ⊢ x : τ 

(x : inenv (τ)) ∈ Γ 

Γ ⊢ lookup x : τ Γ ⊢ i : int 

Γ ⊢ e1 : τ1 → τ2 Γ ⊢ e2 : τ1 

Γ ⊢ apply e1 e2 : τ2 

i ∈ N 

Γ; (x1 : local (τ)1); . . .; (xn : inenv (τ)n); (x : local (τ) ′ ) ⊢ e : τ 

Γ ⊢ closure{x1 = e1 . . . xn = en|x ⊲ e} : τ ′ → τ 

Γ; (x : τ1 → τ2) ⊢ e : τ1 → τ2 

Γ ⊢ fix x. e : τ1 → τ2 

Γ; x : local (τ1) ⊢ e2 : τ2 

Γ ⊢ let x = e1 in e2 : τ2

Un système de type pour Willow 


| x, . . . Variable 

| f Pointeur sur fonctions 

| 0, 1, . . . , Entier 

| let x = e in e Définition locale 

| e (e, e) Appel de fonction 

| [e1 . . . en] Création d’un bloc 

| e[i] Lecture dans un bloc 

| e[i] ← e Écriture dans un bloc 

v ::= Valeurs 

| 0, 1, . . . , Entier 

| f Pointeur sur fonctions 

| [v1 . . . vn] Bloc 

d ::= f (env, x) = e Définition de fonction

Première tentative 

τ ::= Type 

| int Entiers 


ε ∈ { . →, blocki} 



| Γ; (x : τ) Liaison 

◮ On se donne une famille de constructeurs de type blocki d’arité i. 

◮ L’arité de . → est 3. Le type (τenv, τi) . → τo est celui d’une fonction (close) en 

attente d’un environnement de type τenv et d’une entrée de type τi pour 

produire une sortie de type τo.

Deux exemples problématiques 

Hamlet let at0 = fun (f : int → int) ⇒ f 0 

Clovis let at0 = closure{∅|(f : int → int ⊲ apply f 0} 

Willow let at0 = [atcode 0 ; []] 

(env, f ) = f [0](f [1], 0) 

at code 

0 

Hamlet let compose = fun (f g : int → int) ⇒ fun (x : int) ⇒ f (g x) 

Clovis let compose = 

closure{∅|f : int → int ⊲ 

closure{f = f |g : int → int ⊲ 

closure{f = f ; g = g|x : int ⊲ apply f (apply g x)} 

Willow let compose = [compose code ; []] 

compose code (env, f ) = [composef code ; [f ]] 

composef code (env, g) = [composefg code ; [g; env[0]]] 

composefg code (env, x) = env[1][0](env[1][1], env[0][0](env[0][1], x)) 

◮ Quels types donner à atcode 0 , composecode , composef code et composefg code ?

Appliquer “quelque soit” le type de l’environnement 

Hamlet let at0 = fun (f : int → int) ⇒ f 0 

Clovis let at0 = closure{∅|(f : int → int ⊲ apply f 0} 

Willow let at0 = [atcode 0 ; []] 

(env, f ) = f [0](f [1], 0) 

at code 

0 

◮ Pour que l’expression “f[0] (f[1], 0)” soit bien typée, il faut que le type du 

premier argument attendu par “f[0]” soit le même que celui de “f[1]”. 

◮ Pour un certain type α, f doit donc avoir le type : 

◮ La fonction at code 

0 

block2 ((α, int) . → int, α) 

fonctionne pour tout type α.

Quantification universelle (à la Système F) 

τ ::= Type 

| int Entiers 

| α Variable de types 

| ∀α.τ Type polymorphe 


ε ∈ { . →, blocki} 


| . . . 

| Λα.e Abstraction de type 

| e[τ] Application de type 

| . . . 

◮ Les environnements de typage contiennent des variables de type α.

Nouveaux types, nouvelles règles 

Γ; α ⊢ e : τ 

Γ ⊢ Λα.e : ∀α.τ 

◮ Il est alors possible de réécrire at code 

0 

at code 

0 

Γ ⊢ e : ∀α.τ 

Γ ⊢ e[τ ′ ] : τ[α ↦→ τ ′ ] 

comme ceci : 

= Λαβ.fun (env : α, f : block2 ((β, int) . → int; β)) ⇒ f [0](f [1], 0) 

◮ La fonction atcode 0 suppose l’existence d’un type β pour l’environnement de f 

et se contente de le véhiculer comme une boîte noire. 

◮ Comment est étendue la sémantique opérationnelle de Willow ? 

◮ Quelles implications a l’ajout du polymorphisme sur sa compilation ? 

⇒ Réponses dans peu de temps.

Typage de la composition 

On pose : 

ccode (α) ≡ block2 ((β, int) . → int; β) 


compose code = Λαβ.fun (env : α, f : ccode (β)) ⇒ 

[composef code ; [f ]] 

composef code = Λαβ.fun (env : block1(ccode (α)), 

g : ccode (β)) ⇒ 

[composefg code ; [g; env[0]]] 

composefg code = Λαβγ.fun (env : block2(ccode (α); ccode (β)), 

x : int) ⇒ 

env[1][0](env[1][1], env[0][0](env[0][1], x)) 

◮ Est-ce que ce programme est bien typé ?

Quantification existentielle 

◮ Le typage à l’aide de quantification universelle précise trop la forme des 

environnements des fermetures. 

◮ Par conséquent, les types obtenues dans les fonctions précédentes se 

composent mal. 

◮ Or, “appliquer une fermeture” est un mécanisme local ne faisant intervenir 

que les composantes internes à celle-ci (i.e. son environnement et son code). 

◮ Autrement dit, si une fermeture a été construite avec deux composantes 

cohérentes, on doit pouvoir par la suite l’appliquer dans tout contexte. 

◮ Par contre, on peut oublier la nature exacte de ce type.

Quantification existentielle 

τ ::= Type 

| int Entiers 

| α Variable de types 


| ∃α.τ Type existentiel 


ε ∈ { . →, blocki} 


| . . . 

| pack e as ∃α.τ Empaquetage 

| unpack e as α, x in e Dépaquetage 

| . . .

Nouveaux types, nouvelles règles 

Γ ⊢ e : τ[α ↦→ τ ′ ] 

Γ ⊢ pack e as ∃α.τ : ∃α.τ 

Γ ⊢ e1 : ∃α.τ Γ; α; (x : τ) ⊢ e2 : τ ′ 

Γ ⊢ unpack e1 as α, x in e2 : τ ′ 

◮ Il est alors possible de réécrire atcode 0 comme ceci : 

atcode 0 = Λα.fun (env : α, f : ∃β.block2 ((β, int) . → int; β)) ⇒ 

unpack f as γ, code in code[0](code[1], 0) 

⇒ Vérifiez le bon typage de cette fonction. 

α#τ ′

Solution finale pour le typage des fermetures dans Willow 

On pose : 

closure ≡ ∃β.block2 ((β, int) . → int; β) 


compose code = Λα.fun (env : α, f : closure) ⇒ 

pack [composef code ; [f ]] as closure 

composef code = fun (env : block1(closure), 

g : closure) ⇒ 

pack [composefg code ; [g; env[0]]] as closure 

composefg code = fun (env : block2(closure; closure), 

x : int) ⇒ 

unpack env[1] as α, f 

f [0](f [1], 

unpack env[0] as β, g in 

g[0](g[1], x))

Dualité entre quantification existentielle et universelle 

◮ Comme en logique classique, on peut coder une quantification existentielle 

par double négation d’une quantification universelle. 

pack e as ∃α.τ Λβ.fun (k : ∀α.τ → β) ⇒ k[τe] e 

unpack e1 as α, x in e2 e1[τe 2 ] (Λα.fun (x : τ) ⇒ e2) 

◮ La variable k représente la continuation du calcul. 

◮ Un tel codage est dans un style de passage par continuation. 

⇒ Nous parlerons des avantages de cette forme de termes pour la compilation.

Flexibilité 

Γ ⊢ e1 : τ1 → τ2 Γ ⊢ e2 : τ1 

Γ ⊢ e1 e2 : τ2 

◮ La règle de l’application interdit la dérivation de typage suivante : 

Γ ⊢ f : block2[τ1; τ2] → τ Γ ⊢ [e1; e2; e3] : block3[τ1; τ2; τ3] 

qui est pourtant correcte ! 

Γ ⊢ f [e1; e2; e3] : τ

Sous-typage 

◮ L’ensemble des valeurs du type “blocki (τ1, . . . , τi)” est inclus dans 

l’ensemble des valeurs du type “blockj (τ1, . . . , τj)” pour j ≤ i dans le sens 

où tout ce qu’on peut faire avec une valeur du second type peut être fait 

avec une valeur du second. 

◮ On note cette relation : 

◮ La règle suivante est alors correcte : 

blocki (τ1, . . . , τi) ⊳ blockj (τ1, . . . , τj) 

(Sub) 

Γ ⊢ e : τ τ ⊳ τ ′ 

Γ ⊢ e : τ ′ 

⇒ C’est un principe de substitutivité des valeurs de type τ ′ par celles de type τ. 

⇒ Comment peut-on étendre la relation “⊳” ?

La relation de sous-typage 

◮ Il est clair que la relation “⊳” doit être réflexive : 

τ ⊳ τ 

◮ Le principe de substitutivité est transitif, la relation “⊳” doit l’être aussi : 

τ1 ⊳ τ2 τ2 ⊳ τ3 

τ1 ⊳ τ3

La relation de sous-typage entre types de bloc 

◮ Pour i ≤ j, on a : 


◮ Peut-on étendre cette règle en définissant une relation de sous-typage entre 

les types de chaque composante ? C’est-à-dire : 

i ≤ j ∀k ≤ i, τk ⊳ τ ′ k 

blocki (τ1, . . . , τi) ⊳ blockj (τ ′ 1, . . . , τ ′ 

j )

La relation de sous-typage entre types de bloc 

◮ Pour i ≤ j, on a : 


◮ Peut-on étendre cette règle en définissant une relation de sous-typage entre 

les types de chaque composante ? C’est-à-dire : 

i ≤ j ∀k ≤ i, τk ⊳ τ ′ k 

blocki (τ1, . . . , τi) ⊳ blockj (τ ′ 1, . . . , τ ′ 

j ) 

⇒ Non ! Que dire du programme suivant : 

let a = [[42; 21]] in 

(fun (b : block1(block1(int))) ⇒ b[0] = [17]) a; 

a[0][2] 

⇒ Cette règle est valide si les champs sont uniquement accessibles en lecture ; 

comme c’est le cas, par exemple, pour des n-uplets.

La relation de sous-typage entre types de fonction 

◮ Le constructeur de type ”→” est : 

τ i ? ⊳ τ i ? τ o ? ⊳ τ o ? 

τ i 1 → τ o 1 ⊳ τ i 2 → τ o 2 

◮ contravariant sur le type de l’entrée ; 

◮ covariant sur le type du résultat.

La relation de sous-typage entre types de fonction 

◮ Le constructeur de type ”→” est : 

τ i 2 ⊳ τ i 1 τ o 1 ⊳ τ o 2 

τ i 1 → τ o 1 ⊳ τ i 2 → τ o 2 

◮ contravariant sur le type de l’entrée ; 

◮ covariant sur le type du résultat.

Algorithme de sous-typage 

◮ Il n’est pas difficile de réaliser cette relation de sous-typage à l’aide d’une 

fonction définie par induction sur les deux types à comparer. 

◮ (Une implémentation efficace est cependant plus subtile à mettre en œuvre.) 

◮ Par contre, définir un algorithme de vérification du bon typage d’un 

programme à partir de notre spécification n’est pas immédiat car cette 

dernière n’est pas dirigée par la syntaxe. 

◮ Par chance, on peut prouver qu’il existe une spécification équivalente et 

dirigée par la syntaxe. Il suffit de supprimer la règle (Sub) et de remplacer la 

règle de l’application par : 

Γ ⊢ e1 : (τ i 1, τ i 2) . → τ o 

Γ ⊢ e2 : τ ′i 

1 

Γ ⊢ e3 : τ ′i 

2 

τ ′i 

1 ⊳ τ i 1 

τ ′i 

2 ⊳ τ i 2 

Γ ⊢ e1 (e2, e3) : τ o 

◮ Il suffit donc de vérifier la relation de sous-typage entre les types attendus 

par une fonction et les types de ses arguments réels.

Un système de type pour Toby 


| x Variable 

| 0, 1, . . . , Entier 

| e.m(e) Appel de méthode 

| new {d} Création d’objet 

| δ(e) Application d’une primitive 

d ::= Déclaration 

| x = e Attribut 

| m x = e Méthode 

Est-ce suffisant pour définir un système de type pour Toby ?

Un système de type pour Heracles 


| x Variable 

| 0, 1, . . . , Entier 

| e.m(e) Appel de méthode 

| new A (e) Création d’objet 

| δ(e) Application d’une primitive 


| x = e Attribut 

| m x = e Méthode 

c ::= class A(x) ⊳ A(e){d} Déclaration de classes 

Est-ce suffisant pour définir un système de type pour Heracles ?

Différences entre les sous-typage de Toby et d’Heracles 

◮ Dans Toby, c’est la structure des valeurs et, uniquement celle-ci, qui 

contribue à la relation de sous-typage. On parle de sous-typage structurel. 

◮ Dans Heracles, la relation de sous-typage entre deux noms de type est 

déclarée par le programmeur en même temps que la relation d’héritage (et 

vérifié une fois pour toute). On parle alors de sous-typage nominal. 

⇒ Comparez ces deux approches du point de vue de : 

◮ l’implémentation d’un vérificateur de types ; 

◮ l’expressivité du langage de programmation ; 

◮ l’implémentation d’un interprète ( ?)

Représentation des valeurs d’Heracles 

x1 • 

B 42 21 

A 

f y = y + x 

x ↦→ 0 

x2 • 

B 17 73 

x3 • 

A 21 

B 

inherits A 

y ↦→ 1 

◮ La relation de sous-typage nominal induit naturellement une 

représentation uniforme des données. 

◮ Chaque instance contient une étiquette déduite du nom de sa classe. 

◮ Une table associe une description à chaque étiquette. 

◮ L’accès à la variable x dans la méthode f se fait toujours à l’indice indiqué 

par le descripteur de A, que l’instance considérée soit un A ou un B.

Test d’appartenance 

i ∈ T ? 

◮ Les étiquettes permettent une implémentation efficace de la 

primitive instanceof. 

⇒ On peut affecter un entier à chaque classe et réduire ce test à une séquence 

de comparaison entre entiers.

Stratégie d’indexation des étiquettes 

B [1;3] 

D E 

◮ L’étiquette est un entier. 

A [0;10] 

C [4;10] 

. . . . . . 

◮ instanceof est une comparaison entre l’entier représentant l’étiquette d’une 

instance et les deux bornes de la classe considérée. 

⇒ Comment rajouter de nouvelles classes dynamiquement dans ce modèle ? 

⇒ Nous avons encore fait une hypothèse de monde clos . . .

Stratégie d’indexation incrémentale des étiquettes 

B [0;0] 

D [0;0;0] E [0;0;1] 

A [0] 

C [0;1] 

. . . . . . 

◮ L’étiquette est le chemin menant de la racine à la classe. 

◮ instanceof est une comparaison entre ce chemin et le préfixe de l’étiquette 

de l’instance considérée.

Représentation des valeurs dans Toby 

◮ Pour autoriser un mécanisme de partage de la méthode f , il faut que le code 

de celle-ci soit indépendant de l’emplacement des champs. 

◮ Une nouvelle indirection semble nécessaire. 

x1 • 42 21 x2 • 17 73 x3 • 21 

x ↦→ 1 

y ↦→ 0 

convert 

f y = y + x 

x ↦→ 0

Compilation par introduction de coercions 

◮ Le sous-typage contraint la représentation des données en forçant une 

représentation uniforme ou en introduisant une indirection supplémentaire au 

moment de l’exécution. 

◮ Une autre stratégie consiste à traduire un programme Toby faisant usage de 

la relation de sous-typage en un programme Toby n’utilisant pas cette règle. 

◮ Pour cela, il suffit de traduire chaque dérivation établissant le sous-typage 

entre τ1 et τ2 en une fonction de conversion de type τ1 → τ2, 

appelée coercion.

Exemple de coercion : permutation des méthodes 

 

∀i, Di :: τi ⊳ τ σ(i) 

{(m σ(i) : τ σ(i)) i∈[0...n] } ⊳ {(mi : τi) i∈[0...n] } 

fun o ⇒ new { 

} 

(mi x = (Dio.m σ(i))(x)) i∈{0...n} 

◮ Cette coercion réordonne les méthodes d’un objet pour les présenter suivant 

un arrangement attendu par une fonction. 

 

=

Suppression de deux indirections 

x1 • 42 21 x2 • 17 73 x3 • 21 

x ↦→ 1 

y ↦→ 0 

convert 

f y = y + x 

x ↦→ 0 

◮ La fonction convert est appliquée à l’argument avant l’appel de la 

méthode f . 

◮ L’accès au champs x est un simple décalage de pointeur. 

◮ On profite de la connaissance du type exact des arguments de f pour la 

compiler efficacement.

Représentation des données en présence de polymorphisme 

◮ Comment manipuler des données de type inconnu ? 

⇒ Comme dans Heracles, une solution possible consiste à représenter 

uniformément toutes les valeurs par des pointeurs. 

◮ Les données doivent donc être allouées (sur le tas) et tout calcul doit 

préalablement les déréférencer. 

◮ Un entier pourrait être stocké plus efficacement dans un registre . . . 

⇒ Comment traiter ces cas particuliers ? 

◮ Unboxed objects and polymorphic typing – Xavier Leroy – POPL 92

Le langage Polly 


| x [τ] Variable 

| 0, 1, . . . , Entier 


| (e, e) Pair 


| letrec x : σ = e in e Définition récursive 

τ ::= Type 

| α Variable de type 

| int Entiers 

| τ × τ N-uplets 


σ ::= ∀α.τ Schéma de type

Problème du polymorphisme 

let make_pair x = (x, x + 1) in 

let p = make_pair [int] 0 in 

fst p + snd p 

◮ La fonction make_pair est polymorphe et de type : 

∀α.α → α × α


◮ La fonction make_pair peut produire une paire à partir de la représentation 

de taille inconnue d’une valeur x de type inconnu α de la façon suivante : 

x 

make_pair 

◮ On connaît toujours la taille d’une adresse. 

x 

• • 

⇒ Deux déréférencements sont nécessaires pour accéder à la valeur d’une 

composante. 

•


◮ Si la taille de la représentation de x est connue alors make_pair peut 

produire une paire plus compacte : 

make_pair 

x x x

Quelques solutions 

◮ On peut spécialiser la fonction make_pair pour chacune de ses instantiations 

effectives. 

⇒ Duplication du code ; 

⇒ Temps de compilation important ; 

⇒ Hypothèse de monde clos. 

◮ À l’exécution, on peut associer un descripteur de type à chaque valeur et 

l’observer pour se comporter de façon adéquate. 

⇒ Machinerie complexe ; 

⇒ Sous-optimal. 

◮ On peut : 

1. choisir une représentation mixte où les valeurs de type inconnu sont 

accessibles à travers des pointeurs tandis que les valeurs de type simple 

(entier, flottant, etc) sont des valeurs immédiates ; 

2. convertir les valeurs immédiates en pointeur lorsqu’elles sont manipulées dans 

un contexte polymorphe et convertir les pointeurs en valeurs immédiates 

lorsqu’elles sont produites par un contexte polymorphe. 

◮ On introduit wrap(τ) qui traduit une valeur de type τ en un pointeur et 

unwrap(τ), l’opération inverse.

Règle d’instanciation 

◮ La technique d’insertion de coercion est utilisable de nouveau. 

◮ Il suffit de suivre la dérivation de typage du programme source en traduisant 

les instanciations de variables polymorphes par des coercions effectuant les 

traductions expliquées dans le transparent précédent : 

Γ(x) = ∀α.τ ρ ≡ α ↦→ τ 

Γ ⊢ x [τ] : ρ(τ) ⇒ Sρ(x : τ) 

◮ La traduction Sρ(e : τ) est définie conjointement à une fonction 

duale Gρ(e : τ) : 

Sρ(e : α) = unwrap(ρ(α))(e) 

Gρ(e : α) = wrap(ρ(α))(e) 

Sρ(e : int) = Gρ(e : int) = e 

Sρ(e : τ1 × τ2) = Gρ(e : τ1 × τ2) = let x = e in 

(Sρ(fst(x) : τ1), Sρ(snd(x) : τ2)) 

Sρ(e : τ1 → τ2) = fun x.Sρ(e(Gρ(x : τ1)) : τ2) 

Gρ(e : τ1 → τ2) = fun x.Gρ(e(Sρ(x : τ1)) : τ2)

Application sur l’exemple 

devient 


let p = make_pair [int] 0 in 

fst p + snd p 


let p = (fun x → 

let r = make_pair [int] (wrap (int) x) in 

(unwrap (int) (fst r), unwrap (int) (snd r))) 0 

in 

fst p + snd p

Le langage Apollo 


| x Variable 

| 0, 1, . . . , Entier 

| e.m[τ](e) Appel de méthode 

| new τ ()e Création d’objet 

| δ[τ](e) Application d’une primitive 


| x : τ = e Attribut 

| m [α](x : τ) : τ = e Méthode 

c ::= class A[α](x) ⊳ A[τ](e){d} Déclaration de classes 

τ ::= Type 


| int Entiers 


| A[τ] Classe instanciée

Compilation par effacement partiel des types 

◮ Tout programme écrit en Heracles peut être traduit en un programme écrit 

en Apollo. 

◮ Un type “Object” vide est introduit et il est sur-type de tout type. 

◮ Toute variable de type est remplacée par “Object”. 

◮ Toute instanciation de classe paramétrée A[τ] est remplacée par une classe 

non paramétrée A. 

◮ (C’est ainsi que sont implémentés les Generics de Java.)

Test d’appartenance 

◮ L’effacement rend imprécise la fonction instanceof. 

◮ Si on a “x : list[int]”, alors le test “instanceof[list[string]](x)” réussit.

Compilation par réification des types 

◮ La réification des types consiste à donner une existence concrète aux types 

durant l’exécution. 

◮ Une méthode polymorphe paramétrée par les types α1, . . . , αn est traduite 

en une méthode attendant n + 1 arguments. 

⇒ Une représentation dynamique des types est nécessaire. 

⇒ Une implémentation efficace n’est pas simple à mettre en œuvre. 

⇒ Nous aborderons ce sujet dans le cours sur les machines virtuelles.

Formulation du problème de l’inférence de type 

◮ L’inférence de type est un procédé visant à reconstruire la dérivation de 

typage d’un programme sans (ou avec un minimum) d’annotations de type. 

◮ L’inférence de type se réduit à la résolution d’une contrainte entre types.

Réduction à la résolution de contraintes 

◮ On se donne une syntaxe pour les contraintes : 

U ::= 

| τ = τ 

| ∃α.U 

| U ∧ U 

| ⊥ 

| ⊤ 

◮ La contrainte de typage pour qu’une expression e soit de type τ est notée : 

Γ ⊢ t : τ

Réduction à la résolution de contraintes 

◮ Γ ⊢ x : τ = (Γ(x) = τ). 

◮ Γ ⊢ t1 t2 : τ = ∃α.( Γ ⊢ t1 : α → τ ∧ Γ ⊢ t2 : α ) 

◮ Γ ⊢ fun x ⇒ t : τ = ∃αα ′ .(α → α ′ = τ) ∧ Γ (x : α) ⊢ t : α ′

Résolution de contraintes 

◮ La résolution des contraintes est ici très simple. Il s’agit de traiter chacune 

des composantes des conjonctions et d’en conclure la valeur des variables 

introduites existentiellement. 

◮ Mais comment résoudre les équations de la forme 

? 

α ′ → α = int → int

Unification du premier ordre 

◮ Une substitution est une application qui associe des termes du premier ordre 

aux variables. 

◮ L’application d’une substitution φ à un terme t, notée ˜ φ t est définie ainsi : 

˜φ (f t1 . . . tn) = f ( ˜ φ t1) . . . ( ˜ φ tn) 

◮ Soit une égalité entre deux termes du premier ordre t = t ′ . Le problème 

d’unification du premier ordre consiste à trouver une substitution de type φ 

telle que φ t = φ t ′ . 

◮ Une substitution peut être modélisée par une contrainte de la forme : 

∃α.α1 = t1 ∧ . . . ∧ αk = tk 

◮ On modélise donc l’unification du premier ordre comme la réécriture d’une 

contrainte .

Multi-équation 

◮ Lors de la résolution, on doit "fusionner" les égalités. 

◮ Par exemple, α = τ1 ∧ α = τ2 deviendra α = τ1 = τ2. 

◮ On se donne une syntaxe pour ses multi-equations qui remplaceront les 

équations dans les contraintes : 

ɛ ::= 

| τ1 = . . . = τn

Multi-équation 

Definition (Multi-équation standard) 

Une multi-équation est dite standard si toutes les variables qui la composent sont 

distinctes et si elle contient au plus un terme qui n’est pas une variable. 

◮ α = β = (int → int) est standard. 

◮ α = α = (int → int) n’est pas standard. 

◮ α = α = (int → int) = int n’est pas standard. 

◮ α = (int → int) = (int → β) n’est pas standard.

Implémentation des multi-équations 

◮ Les multi-équations représentent des classes d’équivalence de variables qui 

peuvent être toutes égales à un terme ou bien indéterminées. 

◮ L’algorithme d’unification doit fusionner ses classes lorsque deux variables de 

deux classes a priori différentes sont mises en correspondance. 

◮ L’algorithme d’unification doit trouver le terme associé à une variable 

quelconque, c’est-à-dire connaître sa classe d’équivalence, pour pouvoir 

égaliser les termes associés à deux variables qu’on met en correspondance. 

◮ L’algorithme Union/Find de Tarjan répond exactement à ces deux problèmes 

en temps quasi-constant.

Domination 

Definition (Domination) 

Si U est une conjonction de multi-équations. Une variable α est dominée par β 

dans U, noté α U β, si parmi les multi-équations, il en existe une telle que 

β = τ avec α qui est une variable libre de τ. 

Definition (Cyclicité) 

U est cyclique si le graphe de U est cyclique.

Spécification de l’unification 

◮ L’unification a pour état une conjonction de multi-équations en forme 

standard implémentée par l’ensemble des classes d’équivalence du 

Union/Find. C’est l’ensemble des équations traitées jusqu’à maintenant. 

◮ Elle traverse la contrainte d’unification à résoudre et prend en compte 

chaque égalité binaire pour en déduire un nouvel état du Union/Find.

Spécification de l’unification 

U1 ∧ ∃α.U2 → ∃α.(U1 ∧ U2) 

si α /∈ FV(U1) 

α = ɛ ∧ α = ɛ ′ 

→ α = ɛ = ɛ ′ 

α = α = ɛ → α = ɛ 

f t1 . . . ti . . . tn = ɛ → ∃α.(α = ti ∧ f t1 . . . α . . . tn = ɛ) 

f α1 . . . αn = f t1 . . . tn = ɛ → α1 = t1 ∧ . . . ∧ αn = tn ∧ f α1 . . . αn = ɛ 

f t1 . . . tn = g t ′ 1 . . . t ′ n = ɛ → ⊥ 

t → ⊤ 

U ∧ ⊤ → U 

U → ⊥ 

si U est cyclique 

U[⊥] → ⊥

Propriétés du solveur 

◮ → est fortement normalisable. 

◮ Si U → U ′ alors U ≡ U ′ .

Propriétés du solveur 

◮ Les formes normales de ce solveur sont : 

◮ ⊥, dans ce cas, la contrainte n’est pas satisfiable ; 

◮ une conjonction de multi-équations standards. 

◮ Une multi-équation en forme standard représente une substitution.

Solveur de contraintes 

◮ Le solveur va aussi être spécifié sous la forme d’un système de réécriture. 

◮ L’état du solveur utilise une pile qui dénote la partie de la syntaxe qu’il reste 

à résoudre : 

S ::= 

| [] 

| S[[] ∧ C] 

| S[∃α.[]] 

◮ [] correspond à la position courante du solveur dans la contrainte. 

◮ L’état du solveur est un triplet S; U; C. 

◮ S correspond au contexte dans lequel on résout la contrainte U ∧ C. 

◮ U est l’ensemble des classes d’équivalence de variables courantes. C’est 

l’information connue jusqu’à maintenant. 

◮ C est la contrainte qu’on résout.


S; U; C → S; U ′ ; C 

si U → U ′ . 

S; ∃α.U; C → S[∃α.[]]; U; C 

si α /∈ FV(C). 

∃α.S ′ ∧ C; U; C → ∃α.(S ′ ∧ C); U; C 

S; U; τ1 = τ2 → S; U ∧ τ1 = τ2; ⊤ 

S; U; C1 ∧ C2 → S[[] ∧ C2]; U; C1 

S; U; ∃α.C → S[∃α.[]]; U; C 

S[[] ∧ C]; U; ⊤ → S; U; C


◮ La spécification du slide précédent est une formalisation formelle du solveur. 

◮ Les preuves de correction du solveur vis-à-vis de la sémantique des 

contraintes sont faites par rapport à cette spécification. 

◮ Ces règles nous expliquent simplement : 

◮ qu’il faut traiter les composantes des conjonctions une à une. 

◮ qu’il faut résoudre les problèmes d’unification. 

◮ que les variables existentielles doivent être globalement fraîches.

Exemple 

◮ Résoudre la contrainte d’unification : 

∃αβ.α → β = int → int

Exemple 

◮ Résolution de la contrainte : 

∃α. (add : int → int → int) ⊢ λx.add x x : α

Polymorphisme implicite, le langage Olimpia 


| x Variable 

| 0, 1, . . . , Entier 


| (e, e) Pair 


| let x = e in e Définition locate 

τ ::= Type 


| int Entiers 

| τ × τ N-uplets 


σ ::= ∀α.τ Schéma de type

Généralisation implicite 

◮ Dans une dérivation de typage, une variable de type non contrainte peut être 

généralisée : 

Gen 

Γ ⊢ e : τ α /∈ FV(Γ) 

Γ ⊢ e : ∀α.τ 

◮ Par exemple, l’identité est polymorphe (elle admet un schéma de type) : 

Gen 

• ⊢ λx.x : α → α α /∈ FV(•) 

• ⊢ λx.x : ∀α.α → α 

◮ Ce procédé de généralisation automatique des types est caractéristique des 

langages de la famille ML.

Instanciation 

◮ Un terme ayant un type polymorphe peut être utilisé dans des contextes de 

typage particulier. 

Inst 

Γ ⊢ t : ∀α.τ 

Γ ⊢ x : [α ↦→ τ]τ

Condition pour généraliser une variable 

◮ Par contre, on ne peut pas généraliser n’importe quelle variable ! 

◮ La dérivation suivante est invalide : 

Gen 

(z : α) ⊢ z : α 

(z : α) ⊢ z : ∀α.α 

◮ Prouvez que ce type n’est absolument pas sûr !

Restriction 

◮ La généralisation et l’instanciation ne sont pas dirigées par la syntaxe. Elles 

sont implicites dans le sens où elles peuvent a priori être appliquées à 

n’importe quel point de la dérivation de typage. 

◮ Dans le cas général, l’inférence de type dans un langage avec types 

polymorphes est indécidable . Nous y reviendrons, il s’agit du problème de 

l’inférence de type pour System F. 

◮ Pour rendre ce problème décidable, on restreint le typage de ML à 

n’introduire des schémas de type (utilisation de la règle Gen) qu’au niveau 

des let.

Restriction 

◮ Dans l’environnement, nous associons maintenant des schémas de type aux 

variables. 

◮ Les règles de typage du λ-calcul restent les mêmes : seuls des types 

monomorphes sont acceptés sur toutes les constructions exceptés les let : 

◮ et les variables : 

Let 

Γ ⊢ t1 : σ Γ (x : σ) ⊢ t2 : τ ′ 

Γ ⊢ let x = t1 in t2 : τ ′ 

Var 

(x : σ) ∈ Γ 

Γ ⊢ x : σ

Restriction 

◮ Comme les schémas de type ne sont acceptés que sur les lets, une dérivation 

de typage n’effectue une généralisation qu’après une règle Let. Les autres 

éventuelles généralisations sont nécessairement suivies d’une instanciation 

pour retrouver un type monomorphe compatible avec les règles du λ-calcul . 

◮ On peut donc supprimer ces successions de règles Gen/Inst et factoriser la 

règle Let et la règle Gen : 

LetGen 

Γ ⊢ t1 : τ Γ (x : σ) ⊢ t2 : τ ′ 

α /∈ FV(Γ) 

Γ ⊢ let x = t1 in t2 : τ ′ 

◮ De même, on peut aussi factoriser la règle Var et la règle Inst : 

VarInst 

(x : σ) ∈ Γ σ τ 

Γ ⊢ x : τ

Inférence de types pour Olimpia 

◮ Dès qu’on rajoute la construction let , les choses se compliquent : on doit 

inférer les applications de la règle Gen et de la règle Inst. 

◮ Heureusement, on sait que la généralisation peut se faire uniquement au 

niveau des let et l’instanciation uniquement au niveau des variables. 

◮ Quelles vont être les contraintes capturant exactement le typage de ses 

constructions ?

Contraintes liées à l’inférence de type 

◮ On se donne deux nouvelles constructions de contraintes : 

C ::= 

| . . . 

| let (x : ∀α[C]τ) in C 

| x τ 

◮ La construction let introduit des variables qui pourront être généralisées .

Contraintes associées 

◮ Grâce au let, il n’est plus nécessaire de maintenir un environnement dans le 

jugement d’inférence. 

◮ let x = t1 in t2 : τ = 

let (x : ∀α[ Γ ⊢ t1 : α ]α) in Γ ⊢ t2 : τ 

◮ Le schéma associé à x est un schéma contraint . 

◮ x : τ = x τ 

◮ x τ signifie 

∃α.(U ∧ (α = τ)) 

si ∀α[U]α est le schéma associé à x dans le contexte courant.

Exemple 

◮ Quelles sont les contraintes liées aux programmes suivants ? 

1. let iszero = λx.(x = 0) in iszero 

2. let id = λx.x in id 0 

3. let app = λf .λx.f x in app id 0

Résolution des contraintes 

S[let (x : ∀α[∃α ′ .[]]τ) in C ′ ]; U; C → S[let (x : ∀αα ′ [[]]τ) in C ′ ]; U; C 

si α ′ /∈ FV(τ). 

S[let (x : ∀α[C ′ ]τ) in ∃α.[]]; U; C → S[∃α ′ .let (x : ∀α[C ′ ]τ) in []]; U; C 

si α ′ /∈ FV(τC ′ ). 

S; U; let (x : ∀α[C ′ ]τ) in C → S[let (x : ∀α[[]]τ) in C]; U; C ′ 

si α ′ /∈ FV(U). 

S[let (x : ∀α[[]]τ) in C]; U; ⊤ → S[let (x : ∀αα[[]]α) in C]; U ∧ α = τ; ⊤ 

S[let (x : ∀αα[[]]α ′ ) in C]; α = β = ɛ ∧ U; ⊤ → 

S[let (x : ∀αα[[]]θ (α ′ )) in C]; β = θ (ɛ) ∧ θ (U); ⊤ 

si α = β et θ ≡ [α ↦→ β]. 

si α /∈ FV(Uτ) et τ n’est pas une variable. 

-


S[let (x : ∀αα[[]]α ′ ) in C]; α = ɛ ∧ U; ⊤ → S[let (x : ∀α[[]]α ′ ) in C]; ɛ ∧ U; ⊤ 

si α ′ /∈ α ∪ FV(ɛU). 

S[let (x : ∀αβ[[]]α ′ ) in C]; U; ⊤ → S[∃β.let (x : ∀α[[]]α ′ ) in C]; U; ⊤ 

si β /∈ FV(C) 

et ∃α.U détermine les β. 

S[let (x : ∀α[[]]α ′ ) in C]; U1 ∧ U2; ⊤ → S[let (x : ∀α[U2]α ′ ) in []]; U1; C 

S[let (x : ∀α[U ′ ]α ′ ) in []]; U; ⊤ → S; U; ⊤ 


et ∃α.U2 ≡ ⊤. 

S; U; x τ → S; U; ∃α.(U ′ ∧ (α = τ)) 

si S(x) = ∀α[U ′ ]α.


Definition (Détermination) 

On dit que C détermine α si quelque soit la valeur des variables libres de C qui 

ne sont pas dans α, il n’y a qu’une unique valeur possible pour les α. 

◮ La contrainte α = β1 → β2 détermine β1β2 et détermine α. 

◮ La contrainte ∃β1.α = β1 → β2 ne détermine pas α.


Dur, dur ... ?


◮ Pas d’inquiétude, nous allons expliquer ces règles. 

◮ Avant cela, nous allons concrétiser un peu plus l’environnement du solveur.


◮ Si on se focalise sur la pile du solveur (le contexte de résolution), on 

remarque qu’on peut écrire le solveur sous la forme d’une fonction récursive 

qui : 

◮ Parcourt la contrainte en profondeur ; 

◮ Résout des problèmes d’unification aux feuilles ; 

◮ En remontant sur les lets, se pose la question de la généralisation des 

variables pour en déduire le schéma de type contraint à inférer. 

◮ Le squelette du solveur est donc : 

let rec solve env = function 

| CAnd (c1, c2) → 

let env = solve env c1 in 

solve env c2 

| CLet (x, Scheme(vs, c1, v), c2) → 

let env = introduce true env vs in 

let env = solve env c1 in 

let gen_vs, old_vs = generalize env in 

let env = solve (bind env x v) c2 in 

pop_let env old_vs 

(* ... *)


◮ La fonction essentielle est la généralisation . 

◮ Pour l’implémenter efficacement, il faut savoir en temps constant pour 

chaque variable à quelle profondeur de let elle a été introduite . 

◮ On associe à chaque variable un rang dénotant cette profondeur. 

◮ Que doit-on faire du rang lorsqu’on unifie deux variables ? 

◮ Plus généralement, que faire lorsqu’on introduit une variable de rang k dans 

une multi-équation dont toutes les variables ont un rang k ′ ? 

◮ On dira qu’une variable est vieille lorsqu’elle est introduite par un let 

englobant le plus profond let en cours de résolution. 

◮ On dira qu’une variable est jeune lorsqu’elle est introduite par le plus profond 

let en cours de résolution.


S[let (x : ∀α[∃α ′ .[]]τ) in C ′ ]; U; C → S[let (x : ∀αα ′ [[]]τ) in C ′ ]; U; C 

si α ′ /∈ FV(τ). 

◮ Les variables existentielles introduites dans la contrainte gauche d’un let sont 

généralisables par le let le plus proche. Quel est le rang de ces variables ?


S[let (x : ∀α[C ′ ]τ) in ∃α.[]]; U; C → S[∃α ′ .let (x : ∀α[C ′ ]τ) in []]; U; C 

si α ′ /∈ FV(τC ′ ). 

◮ Les variables qui interviennent dans la contrainte droite d’un let peuvent 

remonter si elles sont suffisamment fraîches. Quel est le rang de ces 

variables ?


S; U; let (x : ∀α[C ′ ]τ) in C → S[let (x : ∀α[[]]τ) in C]; U; C ′ 

si α /∈ FV(U). 

◮ Les variables introduites par un let doivent être fraîches. Quel est le rang de 

ces variables ?


S[let (x : ∀α[[]]τ) in C]; U; ⊤ → S[let (x : ∀αα[[]]α) in C]; U ∧ α = τ; ⊤ 

si α /∈ FV(Uτ) et τ n’est pas une variable. 

◮ Les types intervenants dans les lets peuvent être des variables qui jouent le 

rôle de pointeurs. Ainsi, on augmente le partage et on minimise la recopie. 

◮ Ce partage est nécessaire pour obtenir une complexité linéaire en moyenne 

de l’algorithme. 

◮ En particulier, on doit maintenir l’invariant que tout type introduit dans un 

let de rang k est associé à une multi-équation de rang k.


S[let (x : ∀αα[[]]α ′ ) in C]; α = β = ɛ ∧ U; ⊤ → - 

S[let (x : ∀αα[[]]θ (α ′ )) in C]; β = θ (ɛ) ∧ θ (U); ⊤ 

si α = β et θ ≡ [α ↦→ β]. 

◮ Lorsque deux variables sont mises en correspondance par une équation, on 

peut substituer l’une par l’autre dans toute la contrainte. Cette règle justifie 

l’utilisation de l’algorithme Union/Find. Les variables sont moralement 

dénotées par le représentant de leur classe d’équivalence.


S[let (x : ∀αα[[]]α ′ ) in C]; α = ɛ ∧ U; ⊤ → S[let (x : ∀α[[]]α ′ ) in C]; ɛ ∧ U; ⊤ 

si α ′ /∈ α ∪ FV(ɛU). 

◮ On peut "jeter" les variables qui n’ont plus de rôle dans la contrainte.


S[let (x : ∀αβ[[]]α ′ ) in C]; U; ⊤ → S[∃β.let (x : ∀α[[]]α ′ ) in C]; U; ⊤ 

si β /∈ FV(C) 

et ∃α.U détermine les β. 

◮ On peut partionner l’ensemble des variables généralisables au niveau d’un let 

en deux parties : l’une représentant les variables qui sont les paramètres 

véritables de la contrainte let et les variables qui sont indépendantes de cette 

contrainte.


Theorem (Décision de la détermination) 

Soient α et β deux ensembles de variables distinctes. 

◮ Si ɛ est γ = ɛ ′ avec γ /∈ αβ et β ⊆ FV(ɛ ′ ), 

◮ ou bien ɛ est β = τ = ɛ ′ avec FV(τ) sans intersection avec les α et β. 

◮ Alors ∃α.(C ∧ ɛ) détermine les β. 

◮ Cas 1 : α = β1 → β2 avec α vieille alors β1 et β2 sont déterminées par cette 

équation. 

◮ Cas 2 : α = β1 → β2 avec β1 et β2 vieilles alors α est déterminées par cette 

équation.


◮ On peut en déduire un algorithme efficace pour résoudre le problème 

suivant : soit ∃α.U, trouver β telles que ∃(α \ β).U détermine les β. 

◮ Réfléchissez un peu sur l’exemple : 

let (x : ∀α1α2α3[let (y : ∀β1β2β3[β1 = α2 → α3 ∧ α1 = β2 → β3]β1) in ⊤]α1) in ⊤


◮ L’algorithme cherche à déterminer parmi les α, celles sont qui sont devenues 

vieilles après unification. 

◮ On parcourt donc U pour mettre à jour les rangs des variables. 

◮ Les variables dont le rang sera resté égal au rang du let courant pourront 

être généralisées : elles ne sont pas déterminées par des variables plus vieilles. 

◮ La mise à jour des rangs utilisent ces deux propriétés (venant du théorème 

précédent) : 

1. Etre dominé par une variable plus vieille rend vieux. 

2. Si toutes les variables que dominent une variable sont vieilles alors cette 

variable est vieille.


◮ L’algorithme commence donc par propager la vieillesse des variables les plus 

vieilles vers leurs successeurs par la relation de domination. 

◮ Les successeurs propagent ensuite leur vieillesse vers les variables dominantes.


S[let (x : ∀α[[]]α ′ ) in C]; U1 ∧ U2; ⊤ → S[let (x : ∀α[U2]α ′ ) in []]; U1; C 


et ∃α.U2 ≡ ⊤. 

◮ Le traitement du membre gauche d’une contrainte let est terminé si 

l’ensemble des informations apprises sur les variables liées sur cet let est 

satisfiable.


S[let (x : ∀α[U ′ ]α ′ ) in []]; U; ⊤ → S; U; ⊤ 

◮ Une fois qu’on a montré que la partie droite d’une contrainte let est 

satisfiable, on peut dépiler le let.


S; U; x τ → S; U; ∃α.(U ′ ∧ (α = τ)) 

si S(x) = ∀α[U ′ ]α. 

◮ L’instanciation de x, c’est la duplication du schéma associé à x dans la 

contrainte courante. Il faut bien sûr choisir les α frais.

Les transparents du cours - PPS

Create successful ePaper yourself

Delete template?

Save as template?