Sp ´ecification

(1)

Introduction Des types aux contraintes Analyse de flots d’information Types alg ébriques g én éralis és Conclusion 1

Types et contraintes

Franc¸ois Pottier

15 d ´ecembre 2004

(2)

Types

Un type est une description concise du comportement d’un fragment de programme.

Le typage peut fournir des garanties de sûret é ou de s écurit é.

Il favorise ´egalement la modularit ´e et l’abstraction.

(3)

Contraintes

Un fragment de programme admet un type si et seulement si chacun des sous-fragments qui le composent admet lui-même un type, et si ces types sont coh érents les uns vis- à-vis des autres.

Un problème d’inf érence de types s’exprime donc typiquement sous forme d’une contrainte compos ée de pr édicats sur les types, de conjonctions, et de quantifications existentielles.

De plus, les contraintes peuvent participer à la sp écification même d’un système de types.

(4)

Des types aux contraintes

Le syst`eme de types de Damas et Milner Une approche `a base de contraintes HM(X)

Analyse de flots d’information Pr ´esentation

Techniques

Types alg ébriques g én éralis és

Des types alg ébriques aux types alg ébriques g én éralis és Applications

De HM(X) `a HMG(X) Conclusion

(5)

Introduction Des types aux contraintes Analyse de flots d’information Types alg ébriques g én éralis és Conclusion

Le syst`eme de types de Damas et Milner 5

Techniques

(6)

Sp ´ecification

La sp écification classique du système de types de Damas et Milner est un jeu de règles permettant de d ériver des jugements:

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

Γ`λx.e:τ1→τ2

Γ`e1:τ1→τ2

Γ`e2:τ1

Γ`e1e2:τ2

Γ`e₁ :σ Γ;x:σ`e2:τ Γ`letx=e₁ine₂:τ

Γ`e:τ α¯# ftv(Γ) Γ`e:∀α.τ¯

Γè:∀¯α.τ Γè: [~τ/~α]τ L’ex écution d’un programme bien typ é ne peut échouer.

(7)

L’algorithme J de Milner (extrait)

L’algorithme attend un pr ´e-jugement Γ`e, produit un type τ, et emploie deux variables globales V et φ.

J(Γè₁e₂) = doτ₁=J(Γè₁) doτ₂=J(Γè₂) doα= fresh

doφ←mgu(φ(τ₁) =φ(τ₂→α))◦φ returnα

J(Γ`letx=e1ine2) = doτ1=J(Γè1) letσ=∀ftv(φ(Γ)).φ(τ1) returnJ(Γ;x:σ è₂) Production et r ésolution d’ équations sont entremêl ées.

(8)

Correction et compl ´etude de l’algorithme J

Th ´eor`eme (Correction)

Si J(Γè) termine dans l’ état (φ, V) et renvoie τ, alors φ(Γ)è:φ(τ) est un jugement.

Th éorème (Compl étude)

Soit Γ un environnement de typage. Soit (φ0, V0) un ´etat

satisfaisant les invariants de l’algorithme. Supposons donn és θ₀ et τ₀ tels que θ₀φ₀(Γ)è:τ₀ soit un jugement. Alors, l’ex écution de J(Γè) à partir de l’ état initial (φ0, V0) r éussit. Soient (φ₁, V₁) son état final et τ₁ le type renvoy é. Alors il existe une substitution θ₁ telle que θ₀φ₀ et θ₁φ₁ co¨ıncident en dehors de V0 et telle que τ0 s’ écrit θ1φ1(τ1).

(9)

Compl ´etude de l’algorithme J (extrait de la preuve)

[...] Nous avons

θ1φ1(γ) =θ1ψφ⁰₂(γ) =θ⁰⁰₂φ⁰₂(γ).

Puisque α est distinct de γ et hors de port ´ee de φ⁰₂, nous pouvons continuer avec

θ⁰⁰₂φ⁰₂(γ) =θ⁰₂φ⁰₂(γ) =θ⁰₁φ⁰₁(γ) =θ0φ0(γ).

θ₁φ₁ et θ₀φ₀ co¨ıncident donc en dehors de V₀ [...]

(10)

Une approche `a base de contraintes 10

Techniques

(11)

Syntaxe

La syntaxe des contraintes et des sch ´emas de types contraints sera la suivante:

C ::= τ≤τ|C∧C| ∃α.C|xτ|defx:σinC σ ::= ∀¯α[C].τ

(12)

Interpr ´etation

Les contraintes sont interpr ét ées dans un modèle logique.

Une variable α d énote un él ément d’un univers de Herbrand.

Une variable x d énote un ensemble de tels él éments.

L’interpr étation logique des contraintes est d éfinie de façon à satisfaire les lois

defx:σ inC≡[σ/x]C

(∀¯α[C].τ)τ⁰≡ ∃¯α.(C∧τ≤τ⁰)

(13)

Production

A une expression` e et un type τ, on associe une contrainte Je:τK, n ´ecessaire et suffisante pour que e admette le type τ.

Jx:τK = xτ Jλx.e:τK = ∃α₁α₂.

defx:α1inJe:α2K α₁→α₂≤τ

Je₁e₂:τK = ∃α.(Je₁:α→τK∧Je₂:αK) Jletx=e1ine2:τK = letx:∀α[Je1 :αK].αinJe2:τK Cette sp écification est équivalente aux pr éc édentes.

(14)

HM(X) 14

Techniques

(15)

HM(X) 15

Sp ´ecification

Les jugements font explicitement apparaˆıtre une contrainte:

Γ(x) =σ C∃σ C,Γ`x:σ

C,Γ;x:τ₁`e:τ₂ C,Γ`λx.e:τ1→τ2

C,Γ`e1:τ1→τ2

C,Γ`e2:τ1

C,Γ`e₁e₂:τ₂

C,Γ`e1:σ C,Γ;x:σ `e2:τ C,Γ`letx=e₁ine₂:τ

(16)

HM(X) 16

Sp ´ecification (suite)

Cette contrainte joue le rˆole d’hypoth`ese lorsque l’on souhaite prouver qu’une assertion portant sur les types est satisfaite.

C∧D,Γ`e:τ α¯# ftv(C,Γ) C∧D,Γ`e:∀α[D].τ¯

C,Γ`e:∀α[D].τ¯ CD C,Γ`e:τ

C,Γ`e:τ Cτ≤τ⁰ C,Γ`e:τ⁰

C,Γ`e:σ α¯# ftv(Γ, σ)

∃α.C,¯ Γè:σ La pr ésence d’une contrainte dans les jugements conduit naturellement à l’emploi de sch émas de types contraints.

(17)

HM(X) 17

Les deux facettes de HM(X)

Cette sp écification est équivalente aux règles de production de contraintes pr éc édentes.

Th ´eor`eme

C,Γè:τ est équivalent à CdefΓinJe:τK. Corollaire

Une expression close e est bien typ ´ee si et seulement si la contrainte ∃α.Je:αK est satisfiable.

(18)

Pr ´esentation 18

Techniques

(19)

Pr ´esentation 19

Pourquoi contrˆoler les flots d’information ?

Bob

identit ´e revenus formulaire

logiciel de conseil

fiscal

fournisseur de service

Bob emploie un logiciel pour remplir son formulaire de d éclaration de revenus, lequel communique, à travers le r éseau, avec son site d’origine.

(20)

Pr ´esentation 20

Pourquoi contrˆoler les flots d’information ?

Bob

logiciel de conseil

fiscal

fournisseur de service

Bob souhaiterait obtenir une garantie de secret: s’il modifiait les revenus qu’il d éclare, le fournisseur du logiciel ne pourrait percevoir aucune diff érence. En d’autres termes, les donn ées envoy ées au fournisseur ne d épendent pas des revenus de Bob.

(21)

Pr ´esentation 21

Pourquoi contrˆoler les flots d’information ?

Bob

logiciel de conseil

fiscal

fournisseur de service L

L H

H

Pour sp écifier cela de façon succincte, on attribue des niveaux d’information ordonn és à chaque canal d’entr ée ou de sortie – ici, L < H – et on n’autorise la transmission d’information que

(22)

Pr ´esentation 22

Pourquoi contrˆoler les flots d’information ?

Bob

logiciel de conseil

fiscal

fournisseur de service L

L H

H

Cette sp ´ecification peut prendre la forme d’un type, comme string^L×int^H→string^H×int^L

(23)

Techniques 23

Techniques

(24)

Techniques 24

Polymorphisme

Pour permettre la r éutilisation de code, le système est dot é de polymorphisme vis- à-vis des niveaux, des types, et des effets:

λx.x+ 1 : ∀α.int^α →int^α λx.x : ∀β.β→β

Le polymorphisme permet également d’abstraire une sp écification vis- à-vis du treillis des niveaux d’information:

string^L ×int^H →string^H ×int^L

∀αβ[α≤β].string^α×int^β →string^β ×int^α

(25)

Techniques 25

Sous-typage

Les types habituels sont d écor és par des niveaux, comme L et H. La relation d’ordre entre niveaux donne donc naturellement lieu à une relation de sous-typage structurel entre types.

Le sous-typage permet une analyse orient ´ee des flots d’information:

λ(a, b, c).(b+c, a+c, a+b) :

∀





β≤α⁰ γ ≤α⁰ α≤β⁰ γ≤β⁰ α≤γ⁰ β≤γ⁰



.int^α×int^β×int^γ →int^α⁰×int^β⁰ ×int^γ⁰

(26)

Techniques 26

Contraintes non standard

Le syst`eme emploie ´egalement des contraintes d’ordre entre un niveau et un type:

let choose b x y = if b then x else y

∀αβ[α≤level(β)].bool^α →β→β→β

Une telle contrainte exige, en gros, que “l’ étiquette” port ée par le type β soit born ée inf érieurement par le niveau α.

(27)

Techniques 27

Contraintes non standard (suite)

On dispose ´egalement de contraintes d’ordre entre un type et un niveau:

(=) :∀αβ[content(α)≤β].α→α→bool^β

Une telle contrainte exige, en gros, que le niveau β soit born é inf érieurement par “toutes les étiquettes” du type α.

(28)

Techniques 28

Rang ´ees

Tout constructeur flèche est annot é par une rang ée qui à chaque nom d’exception associe le niveau de l’information trahie par le lancement de cette exception.

λx.(if x then raise X)

∀αβγ[α≤γ∧β≤γ].bool^{α β}→^X:γ unit

(29)

Techniques 29

Sp ´ecification

L’analyse est sp écifi ée par un jeu de règles dont le style rappelle la sp écification de HM(X). Par exemple,

C,Γ`v:bool^λ

∀j ∈ {1,2} C, πtλ,Γ`ej :τ[ρ] Cλ≤level(τ) C, π,Γ`if v then e₁ else e₂:τ[ρ]

(30)

Techniques 30

Inf ´erence de types

L’inf érence de types, donc l’analyse automatique de flots d’information, se ramène comme pr éc édemment à la r ésolution de contraintes. Par exemple,

Jπ`if v then e₁ else e₂:τ[ρ]K=∃αβ.







Jv :bool^αK π≤β∧α≤β Jβ `e₁:τ[ρ]K Jβ `e₂:τ[ρ]K α≤level(τ)







(31)

Techniques 31

R ´esolution de contraintes

Le langage de contraintes consid ér é comprend une relation de sous-typage structurel sur les types, niveaux et rang ées, ainsi que deux relations d’ordre entre types et niveaux et entre niveaux et types.

La complexit é ajout ée par l’analyse vis- à-vis de l’inf érence de types classique est born ée par un facteur constant.

(32)

Des types alg ébriques aux types alg ébriques g én éralis és 32

Techniques

(33)

Les types alg ´ebriques

Les constructeurs de donn ées associ és à un type alg ébrique ordinaire ε reçoivent des sch émas de types de la forme:

K::∀¯α.τ₁· · ·τ_n →ε( ¯α) Par exemple,

Feuille::∀α.arbre(α)

Noeud::∀α.arbre(α)·α·arbre(α)→arbre(α)

Filtrer une valeur de type arbre(α) contre le motif Noeud(l, v, r) lie l, v et r `a des valeurs de types arbre(α), α et arbre(α).

(34)

Les types existentiels `a la L ¨aufer & Odersky

Dans l’extension de ML propos ée par L äufer et Odersky, les constructeurs de donn ées reçoivent des sch émas de types de la forme:

K::∀¯αβ.τ¯ 1· · ·τn →ε( ¯α) Par exemple,

Clef::∀β.β·(β→int)→clef

Filtrer une valeur de type clef contre le motif Clef(v, f) lie v et f `a des valeurs de types β et β→int, pour un β inconnu.

(35)

Les types alg ébriques g én éralis és

Attribuons à pr ésent des sch émas de types contraints aux constructeurs de donn ées:

K::∀¯α¯β[D].τ1· · ·τn →ε( ¯α)

Filtrer une valeur de type ε( ¯α) contre le motif K x₁· · ·x_n lie x_i `a une valeur de type τi, pour des types β¯ inconnus mais qui satisfont la contrainte D.

Si D mentionne ¯β, ceux-ci ne sont que partiellement abstraits.

Si D mentionne ¯α, la r ´eussite du filtrage fournit une information statique suppl ´ementaire sur ces types existants.

(36)

Applications 36

Techniques

(37)

Applications 37

Un exemple typique

Suivant Crary, Weirich et Morrisett, on peut d éfinir un type de descripteurs de types à l’ex écution:

Entier::desc(int)

Paire::∀β₁β₂.desc(β₁)·desc(β₂)→desc(β₁×β₂) Ceci peut ´egalement s’ ´ecrire

Entier::∀α[α=int].desc(α)

Paire::∀αβ₁β2[α=β1×β2].desc(β1)·desc(β2)→desc(α) desc est un constructeur de types singleton, au sens o `u, par exemple, Paire(Entier,Entier) est l’unique valeur de type

(38)

Applications 38

Un exemple typique (suite)

Ceci permet la d éfinition de fonctions g én ériques:

l e t rec print : ∀α.desc(α)→α→unit= fun t → match t with

| Entier → (∗ α=int ∗) p r i n t i n t

| Paire (t1 , t2) → (∗ α=β₁×β₂ ∗) fun (x1 , x2) →

print t1 x1 ; print string ” ∗ ” ; print t2 x2

Les deux branches admettent les types incompatibles int→unit et β₁×β₂→unit, mais elles ont ´egalement un type commun, `a savoir α→unit.

(39)

Applications 39

Lien avec les type classes

Dans un langage dot é de type classes, on aurait pu d éfinir print comme une fonction surcharg ée:

class Printable α where print : : α→unit

Le type de print est alors ∀α[Printableα].α→unit.

(40)

Applications 40

Lien avec les type classes (suite)

On aurait ensuite sp ´ecifi ´e que print est applicable aux entiers et aux produits:

instance Printable int where print = p r i n t i n t

instance Printable β1, Printable β2⇒Printable β1×β2 where print (x1 , x2) = print x1 ; print string ” ∗ ” ; print x2

(41)

Applications 41

Lien avec les type classes (suite)

Il existe une traduction syst ématique de ce programme vers le pr éc édent.

Dans le programme source, le pr édicat Printable (int×int) est d érivable. Dans le programme cible, le type desc(int×int) est habit é par la valeur Paire(Entier,Entier).

(42)

De HM(X) `a HMG(X) 42

Techniques

(43)

Au-del à de l’ égalit é

On peut imaginer de combiner les types alg ébriques g én éralis és avec des langages de contraintes plus riches:

I arithm ´etique de Presburger (Xi)

I polynˆomes complexes (Zenger)

I sous-typage (Tse et Zdancewic)

I et autres ?

Il semble naturel d’ étudier ces combinaisons de façon commune, donc d’ajouter les types alg ébriques g én éralis és à HM(X).

(44)

La facette logique de HMG(X)

La sp écification logique de HM(X) se voit ajouter de nouvelles règles, concernant en particulier les fonctions d éfinies par cas:

C`p:τ⁰ ∃β[D]Γ¯ ⁰ C∧D,ΓΓ⁰ `e:τ β¯# ftv(C,Γ, τ) C,Γ`p.e:τ⁰→τ

L’ex écution d’un programme bien typ é ne peut échouer.

(45)

La facette fonctionnelle de HMG(X)

Une nouvelle r`egle s’applique aux fonctions d ´efinies par cas:

Jp.e:τ₁→τ₂K = Jp↓τ₁K∧ ∀¯β.D⇒defΓ⁰inJe:τ₂K

o `u ∃β[D]Γ¯ ⁰estJp↑τ₁K

Les types alg ébriques g én éralis és exigent la quantification universelle (d éj à requise par les types existentiels à la L äufer &

Odersky) et l’implication.

Comme dans HM(X), les deux sp ´ecifications sont ´equivalentes.

(46)

Un probl`eme ouvert

La contrainte Je:τK est à pr ésent exprim ée (au minimum) dans la th éorie du premier ordre de l’ égalit é dans un univers de Herbrand, pour laquelle le problème de la satisfiabilit é est de complexit é non él émentaire.

Comment restreindre l’ensemble des programmes acceptables, de façon simple, él égante, sans perte d’expressivit é, et de sorte à garantir que le problème de r ésolution de contraintes retrouve une complexit é faible ?

(47)

Techniques

(48)

Un credo

Les contraintes constituent un formalisme d ´eclaratif pour raisonner et calculer `a propos des programmes.

(49)

Et ensuite ?

L’ équipe Cristal veut d éfinir le successeur potentiel d’Objective Caml. Celui-ci devra être plus l éger, plus expressif, et pourrait proposer, entre autres:

I plus de polymorphisme ;

I des modules plus maniables et composables ;

I la possibilit ´e d’exprimer des invariants plus riches.