Document

Programmation
fonctionnelle, impérative, logique et orientée objet
Introduction
●
●
●
●
Les langages de programmation permettent de décrire des calculs de façon plus abstraite qu'un programme “machine”.
Les programmes dans ces langages sont
–
Compilés (transformés en “code machine” par un compilateur)
–
Ou interprétés (exécutés par un autre programme appelé interpréteur)
Un compilateur génère un programme machine pour un processeur donné, dont la sémantique est donnée par le programme source.
Un interpréteur lit un programme source et « calcule » sa sémantique directement pour une entrée donnée
Compilation
(C, Caml, Fortran...)
Programme
Compilateur
(gcc, ocamlopt)
Programme
machine
Processeur
Le programme compilé est très efficace
Entrées
Programme
machine
Sorties
Processeur
Interprétation
(Lisp)
peu efficace
Programme
+
entrées
Interpréteur
Processeur
Sorties
Exemple de compilation : factorielle
Bytecode
Java
int k = 1, l = 1;
while (k <= i) {
l = l * k;
k++;
}
return l;
0: iconst_1
1: istore_2
2: iconst_1
3: istore_3
4: iload_2
5: iload_0
6: if_icmpgt 19
9: iload_3
10: iload_2
11: imul
12: istore_3
13: iinc 2, 1
16: goto 4
19: iload_3
20: ireturn
Compilation
pour une
machine
virtuelle
(Java, Caml, .Net)
Le programme est portable et moyennement efficace
Programme
Compilateur
Programme
“bytecode”
Processeur
Programme
“bytecode”
+ entrées
Machine
virtuelle X
Sorties
Processeur X
Programme
“bytecode”
+ entrées
Machine
virtuelle Y
Processeur Y
Sorties
Machine virtuelle
●
●
●
●
Une machine virtuelle est un programme (compilé) qui exécute des programmes (appelés bytecode). En ce sens, c'est un interpréteur.
Le langage d'entrée est proche d'un langage machine (d'où le nom de machine virtuelle).
Les programmes à exécuter sont obtenus par compilation à partir d'un langage de haut niveau.
Il y a autant de versions de la machine virtuelle (compilée) que de machines réelles différentes.
Conclusion (de l'introduction)
●
●
Les compilateurs, interpréteurs, machines virtuelles se chargent :
–
De l'interface avec une machine simple (processeur réel)
–
des performances (en partie)
–
de la portabilité (exécution sur différentes machines)
Les langages de programmation offrent :
–
une meilleure expressivité (moyens de structurer les programmes, de raisonner de façon plus abstraite)
–
une spécialisation plus ou moins grande pour des types de problèmes (cas extrême : les langages dédiés)
–
certaines garanties de correction, de sécurité, grâce à des concepts sémantiques forts (typage...)
Plan du cours
●
Programmation fonctionnelle
–
●
Programmation impérative
–
●
typage statique (lambda­calcul simplement typé), ramasse­miettes
Programmation orientée objet
–
●
Exemples, portée des identificateurs, gestion de la mémoire, compilation
Typage et gestion de la mémoire
–
●
Exemples, ordre d'évaluation, exécution par interprétation, Exemples, modularité, héritage, liaison dynamique.
Programmation logique
–
Exemples, sémantique déclarative et opérationnelle
Portée des identificateurs
●
●
La portée d'une définition (d'un identificateur) dans une expression est la partie de l'expression dans laquelle cette définition est active. En lambda­calcul, c'est une notion purement syntaxique (donc pas liée à l'exécution).
–
Dans (x.e) e', x est lié à e' dans e, mais uniquement pour les occurrences libres de x dans e.
–
De même pour let x = e' in e (les deux expressions sont d'ailleurs équivalentes)
La portée est illustrée par la propriété suivante de la relation d'alpha­
équivalence :
–
●
si e ~ e' et e  e'' alors il existe e''' tel que e'' ~ e''' et e'  e'''
Cela signifie qu'on peut voir considérer les lambda­termes “à alpha­
équivalence près”.
Extensions du lambda­calcul
●
●
On peut enrichir le lambda­calcul avec
–
Des entiers et des opérateurs : 0, 1, ..., +, en étendant la bêta­
réduction :
(+ 2) 3  5
–
Des paires et des destructeurs : (., .), fst, snd
–
Des constructeurs, pour représenter les “types sommes”
–
Des définitions de constantes locales : let x = e in e
–
La condition : if e then e else e
–
La récursivité : let rec f x = ...f...
Tous ces “ajouts” sont représentables en lambda­calcul pur (cependant pour la récursivité, la terminaison dépend de l'ordre de réduction)
Programmation fonctionnelle
●
●
●
La programmation fonctionnelle pure se contente du lambda­
calcul plus ou moins étendu (exemple : le langage Haskell).
Les lambda­termes clos représentent des fonctions au sens mathématique. Le résultat ne change pas d'un appel à l'autre, il ne dépend pas d'un quelconque « état » ou « contexte » autre que les arguments.
Propriété de transparence référentielle :
On peut toujours remplacer une expression par sa valeur.
–
En particulier, une application de fonction peut être remplacée par son résultat, ou (par transitivité) par l'appel d'une autre fonction « équivalente » à la première. Intuitivement, seul le résultat compte (pas d'effets de bord).
●
●
Les fonctions sont des valeurs comme les autres : au cours de l'exécution on peut les créer, les appliquer, les retourner en résultat, les passer en argument d'autres fonctions.
Les données ont le plus souvent une structure récursive (listes, arbres) ainsi que les fonctions qui les manipulent.
Bêta­réduction et ordre de réduction
●
Bêta­réduction : réduction non déterministe
la substitution e[e ' / x ]est licite
 x.e e' e [e' / x]
●
e e'
 x.e  x.e '
e e'
e e' '  e' e' '
Caml : les arguments d'abord
 x.ee'  e[e ' / x]
x.e est une forme normale
e e'
e ' ' e e' ' e'
(non spécifié officiellement)
e e'
e e' '  e' e' '
e e'
e ' ' e e' ' e'
prioritaire par rapport aux deux autres règles
●
Évaluation paresseuse (Haskell) :
 x.ee'  e[e ' / x]
remplacement sans recopie !
x.e est une forme normale
e e'
e e' '  e' e' '
Ordre de réduction
●
●
L'ordre d'évaluation n'a d'importance que pour :
–
La terminaison (c'est au programmeur d'écrire des programmes qui terminent pour l'ordre considéré, mais cet ordre importe rarement)
–
L'efficacité (certains chemins sont moins coûteux que d'autres)
–
Les programmes impératifs (références, tableaux, entrées­sorties).
Évaluation en caml : opérandes d'abord
–
Toute lambda­abstraction est une valeur (ou forme normale) et n'est donc pas réduite (pensez aux effets de bord, ex :
fun x ­> y := 0)
–
Pour réduire (e e'), on réduit e' jusqu'à obtenir une lambda­
abstraction, puis on réduit e, puis l'expression globale.
Cette réduction est plus faible que la bêta­réduction, (on ne réduit pas “sous les lambda”) mais plus naturelle s'il y a des effets de bord. ●
Évaluation paresseuse (en Haskell par exemple) : on ne réduit que les expressions indispensables, et au maximum une fois.
●
En caml :
(x.y.(+ x x)) (+ 1 1) (+ 2 2)

(x.y.(+ x x)) (+ 1 1) 4

(x.y.(+ x x)) 2 4

(y.(+ 2 2)) 4

+ 2 2

4
●
Évaluation paresseuse : (appel par nom)
(x.y.(+ x x)) (+ 1 1) (+ 2 2)

(y.+ ((+ 1 1) (+ 1 1))) (+ 2 2)
 on ne duplique pas réellement + 1 1
+ (+ 1 1) (+ 1 1)
 + 2 2 n'est jamais évalué
+ 2 2

4 Un interpréteur simplissime
●
Cette fonction évalue un terme clos (c'est à dire sans variable libre).
let rec eval = function
| e e'  let e'r = eval e' in
let x.e'' = eval e in
(* Sinon, on est bloqué *)
eval e''[e'r / x]
| e  e
(* c'est une valeur *)
●
Pour éviter de faire des remplacements coûteux, on préfère évaluer un terme dans un contexte, qui associe des termes à des identificateurs :
let rec eval c = function
| e e'  let e'r = eval c e' in
let x.e'' = eval c e in
eval [e'r / x] :: c e''
| x  c(x)
| e  e
où [e'r / x] :: c est le contexte c enrichi par l'association de x  e'r. Tout identificateur x déjà défini dans c est masqué temporairement (liaison statique).
Remarque historique : si au lieu de masquer x, on le remplace, on obtient ce qui s'appelle la liaison dynamique (présente en Lisp). Ce principe contre­
intuitif remet en cause les bonnes propriétés du lambda­calcul (confluence, renommage, etc.) et n'est plus utilisé (sauf pour les méthodes dans les langages à objets, dans un cadre bien défini).
Programmation impérative
●
L'impératif arrive avec les variables (pointeurs) et les effets de bord
–
●
type 'a ref, val ref, !, :=
Les structures de contrôle permettent de structurer le flot d'exécution de façon intuitive.
–
e ; e'
–
while e do e done
–
for x = e to e do e done
En fait, on pourrait les programmer de façon récursive, connaissant l'ordre d'évaluation de Caml
●
●
Les types de données associés à la programmation impérative sont les tableaux et les structures modifiables “en place” (à champs mutables). Les fonctions ne sont pas des données dans un langage impératif.
Certaines fonctions ne retournent rien et ne sont utiles que par leurs effets de bord. On les appelle des procédures.
Structures de contrôle
●
●
●
Le contrôle “bas niveau” de l'exécution (goto, jump_if_zero), n'est plus utilisé pour programmer (sauf dans certaines applications très spécifiques (code optimisé pour des pilotes...) et aussi par certains vieux physiciens...
En revanche, les return, break, continue de Java peuvent simplifier certains algorithmes.
Les exceptions permettent également de remonter brutalement dans la structure de contrôle, mais elles permettent de plus de fournir une valeur exceptionnelle, qu'on peut utiliser ensuite.
Portée
●
●
●
En caml, les références et les tableaux sont des constantes comme les autres (sauf que l'opération ! ne renvoie pas toujours le même résultat). La portée est donc toujours définie syntaxiquement comme l'expression “sous” le lambda ou le let ... in ...
En C (et dans les autres langages impératifs), on a un tout petit peu moins de liberté : la portée peut être globale (tout le programme) locale à une fonction, à une boucle ou à un bloc (l'équivalent du let ... in ... : {int x ; ...}) le masquage d'une déclaration par une autre est restreint.
Du point de vue de la programmation, il convient de toujours donner aux déclarations la plus petite portée possible.
Compilation des langages impératifs
●
●
En simplifiant à l'extrême (on oublie les données et les optimisations) la compilation consiste à transformer les structures de contrôle de haut niveau en branchements élémentaires compréhensibles par le processeur :
i0 : condition
... : condition
While condition
i1 : jump_if_zero i2
do corps
i1+1 : corps
... : corps
i2­1 : goto i1
i2 : suite
Les tableaux sont représentés par des adresses contiguës et on calcule l'adresse d'une case en ajoutant son indice à l'adresse du tableau. De même pour les types structures.
Typage et gestion de la mémoire
Lambda­calcul simplement typé
(présentation informelle)
●
●
●
Les types :
–
types de base (int, bool) ou variables de types
–
types flèches : si t, t' sont des types, on forme t  t'
Les lambda­termes typés :
–
variables (x, y)
–
applications : e e'
–
abstraction : x:t.e où t est un type et e un lambda­terme typé
où e, e' sont des lambda­termes typés
Jugements de type :
–
Г ├ e : t
où e est un terme, t un type et Г un contexte.
–
(voir règles au tableau)
Sémantique
●
Typage :
–
les règles suivantes définissent le jugement x : t (x est de type t).
x :t ∈
 ├ x :t
●
 , x : t ├ e :t '
 ├  x : t .e: t  t '
Réduction :
–
On choisi les mêmes règles que la bêta­réduction, ou bien une stratégie d'évaluation particulière.
la substitution e[e ' / x ]est licite
  x : t.ee'  e[e ' / x ]
●
 ├ e :t t '  ├ e ': t
 ├ ee ': t '
e e'
 x : t . e  x : t . e'
e e'
e e' '  e' e' '
Aucun programme bien typé ne se bloque
e e'
e ' ' e e' ' e'
Well­typed programs never go wrong
●
●
●
Les types assurent une certaine cohérence aux programmes. Dans un lambda­calcul enrichi, cela se traduit par un théorème sur la réduction :
–
Un programme bien typé ne peut se réduire qu'en un programme bien typé (préservation).
–
Un programme bien typé ne peut être bloqué (progrès). Par exemple, les programmes (1 2), (plus true 0) et (1 := 2) sont bloqués.
Dans la réalité, le bloquage se transforme en des opérations absurdes consistant confondre des entiers et des adresses en mémoire, et inventer des adresses qui ne correspondent à rien. Le typage peut aussi servir à prévenir les accès non­autorisés à un système.
La libération explicite de la mémoire (free) si elle est faite trop tôt, et la conversion de type (cast) cassent le système de types (formellement, la préservation). D'où une interdépendance avec le garbage collector.
●
●
D'après la propriété de préservation, il suffit de vérifier le typage avant exécution, et on peut l'oublier ensuite : le typage est statique.
Parfois, dans les vrais langages, le typage n'est pas entièrement statique : on doit mettre des contraintes explicites qui sont vérifiées à l'exécution (ce qui est coûteux car il faut garder et manipuler des types à l'exécution). C'est le cas en Java (à nuancer avec Java 1.5 et ses classes génériques) :
LinkedList s = new LinkedList();
s.add(new Element());
Element e = (Element) (s.getFirst());
●
Une alternative : les types génériques pour les fonctions et les structures de données. Ces types sont beaucoup plus compliqués à vérifier, surtout si on veut faire de l'inférence.
–
type 'a list = Nil | Cons of 'a * 'a list
–
List.map : ∀'a∀'b ('a ­> 'b) ­> 'a list ­> 'b list
Systèmes de types
●
●
De nombreux langages possèdent :
–
Des types de base : int, char, string, bool
–
Des types pointeurs, tableaux, fonctions
–
La possibilité de définir de nouveaux types produits (structures)
Un système de types est le plus utile lorsqu'il est inviolable. Le langage C au contraire possède un système de types non sûr (pour de raisons de performances et de simplicité). Java, Caml, Haskell ont des systèmes de types sûrs. Lisp est un langage non­typé.
Gestion de la mémoire
●
Reprenons l'interpréteur avec contexte du lambda­calcul :
let rec eval c = function
| ...
| x  eval c (assoc c x)
| ...
●
●
Lorsqu'on doit évaluer x dans un environnement c, on ne va pas recopier la valeur associée à x dans le c : on se contente de retourner la même “zone mémoire”, en espérant qu'elle ne sera pas effacée...
En effet, dans ((a.a)(b.b))((c.c)(d.d)), il faut garder la valeur de c, à savoir (d.d), même après l'avoir dépilée du contexte. En revanche, à la fin, la valeur de a n'a plus d'intérêt.
Le ramasse­miettes
●
●
●
La durée de vie d'un objet peut donc “dépasser” la portée des identificateur auxquels il peut être associé (il peut y en avoir plusieurs) lors de l'exécution.
De plus, on ne peut pas décider statiquement si à tel point de programme un objet peut être libéré ou non (conséquence du théorème de Rice).
On utilise donc un garbage collector : un programme qui, de temps en temps au cours de l'exécution du programme principal, regarde quels objets sont devenus inaccessibles, et les supprime pour récupérer de la mémoire. On sait que dans un langage muni d'un système de types sûr (propriété de préservation définie plus haut), un objet inaccessible l'est définitivement.
Programmation orientée objet
Objectif : associer données et traitements
●
●
Les objets sont des valeurs qui contiennent à la fois
–
un état (des données mutables)
–
des méthodes qui font référence à l'état (de cet objet).
On veut cacher les détails du fonctionnement interne (encapsulation)
class Counter {
private int i;
public Counter {i = 0;}
public int get() {return i;}
public void incr() {i++;}
}
●
Une classe définit à la fois
–
Un type d'objets
–
Des moyens de construire des objets de ce type
–
Leur comportement, de façon générique, au travers des méthodes.
Les éléments d'un langage objet
●
●
●
Objets et classes : représentation de types de données abstraits
–
Les objets : des super­ « records »
–
Les classes : des modèles d'objets
Héritage
–
d'interfaces
–
d'implémentation
La liaison dynamique
–
et la généricité
–
et l'héritage
Composition d'un objet
●
●
●
Des attributs d'instance (comme les champs d'un enregistrement)
–
int n = 10 bool b = true, ...
–
Object x = ...
De méthodes d'instance (qui peuvent accéder aux attributs)
–
void changeNumero(int m) {n = m}
(affectation)
–
bool pair() {return (n mod 2 == 0);}
–
bool greater(Object o) {return (n >= o.n);}
–
bool equals(Object o) {return (greater(o) && o.equals(this));}
–
int factorielle(int i) {if (i == 0) return 1; else return i*factorielle(i­1);}
L'idée est de rapprocher les données et leurs opérations associées.
Composition d'une classe
●
Une classe est un type (comme un type enregistrement)
–
types des attributs d'instance :
●
–
signatures des méthodes
●
●
int n, bool b, Object o, ...
void changeNumero(int), bool pair(), ...
Une classe est un modèle
–
initialisation des attributs par un constructeur
●
–
MaClasse(n, b, o) {this.n = n, this.b = this.b, this.o = o}
corps des méthodes (les attributs sont différents pour chaque objet)
●
void changeNumero(int m) {n = m;}
Définition
En Java
class Counter = {
int x; // un attribut
Counter(x) {this.x = x;} // un constructeur
Counter() {x = 0;} // un autre constructeur
int value() {return x;} // une méthode
void incr(int i) {x = x + i;} // une autre
Utilisation
Counter c1, c2;
c1 = new Counter(3);
c2 = new Counter(4);
c1.incr(2);
int v;
v = c2.value();
...
}
Remarques :
●
●
●
●
Les méthodes sont implicitement mutuellement récursives
this désigne l'objet « courant »
surcharge : dans une même classe, deux méthodes peuvent avoir le même nom, à condition d'être distinguables par les types de leurs arguments.
En Java, tout objet est construit à partir d'une classe, qui est aussi son type.
Champs et méthodes d'instance et de classe
●
●
Les attributs et méthodes « ordinaires » sont dits d'instance
–
class C {... int x; ...}
:
–
class C {... int m(); ...} :
un attribut x par objet de classe C
une méthode m par objet de classe C
Les attributs et méthodes de classe (appelés statiques en Java) existent en un seul exemplaire pour toute la classe.
–
class C {... static int x; ...}
:
un seul x pour toute la classe
–
class C {... static int m(); ...}
:
une seule méthode m
●
Objets et modules sont bien adaptés à la description de types de données abstraits (ADT) : piles, arbres, tables, etc.. Dans la version orientée objet, toutefois, une version modifiable est plus souvent utilisée, pour correspondre au caractère impératif des langages à objets en général.
module List = struct
type 'a t
val nil : 'a t
val cons : 'a ­> 'a t ­> 'a t
val head : 'a t ­> 'a
}
class List {
public static nil = ...
public List cons(Object o) {...}
public Object head() {...}
}
module List = struct
type 'a t
val empty : unit ­> 'a t
val add : 'a ­> 'a t ­> unit
val head : 'a t ­> 'a
}
class List {
impératif
public List () {...}
public void add(Object o) {...}
public Object head() {...}
}
modules
fonctionnel
objets
Liaison dynamique
●
Que se passe­t­il lorsqu'on redéfinit une méthode qui était utilisée par une autre ?
class CounterModulo extends Counter {
class Counter {
int x;
void incr(int i) {x = x + i;}
void incr1() {incr(1);}
}
●
void incr(int i) {x = x + i % 2;}
}
Counter c = new CounterModulo();
c.incr1() ; c.incr1();
La liaison est dynamique : on ne connaît la méthode incr à appeler qu'au moment de l'exécution : c'est celle qui est définie dans la classe de l'objet c, c'est à dire CounterModulo. Autre exemple :
Counter [] counters = {new Counter(), new CounterModulo()};
for (i = 0 ; i < 2 ; i++) counters[i].incr();
●
Il est impossible en général (indécidable), de savoir ●
quelle méthode sera appelée effectivement.
Compatibilité et liaison dynamique
●
Des objets qui partagent un certain nombre de méthodes (même nom, même signature) ont une certaine compatibilité :
class List {
...
public void add(Object o) {...}
}
●
class Set {
...
public void add(Object o) {...}
}
L'intérêt des objets est qu'on peut appeler la méthode add d'un objet sans connaître son type exact (ce serait impossible avec des données simples et des fonctions add associées). Il s'agit d'une liaison dynamique (contrôlée).
Héritage
●
●
Une interface en regroupe des signatures de méthodes qu'un objet doit posséder pour implémenter cette interface : c'est la notion de type pour les objets.
L'héritage d'interface (sous­typage) est un moyen d'étendre une interface en ajoutant des méthodes ; les objets qui implémentent une sous­interface sont alors compatibles avec la super­interface :
interface Collection {
public void add(Object o);
public bool isEmpty();
}
interface List extends Collection {
public Object get(int Index);
}
Héritage
●
L'héritage d'implémentation (simple) permet d'étendre une classe en une autre en lui ajoutant des attributs et des méthodes. Il permet le partage de méthodes entre différentes classes :
class RazCounter extends Counter {
class Counter {
int x;
void incr(int i) {x = x + i;}
}
●
●
void raz() {x = 0;}
}
class ProgramCounter extends Counter {
Instruction [] prog;
Instruction next() {return prog[x];}
}
Une classe peut utiliser les méthodes et attributs de sa super­classe
class UnCounter extends Counter {
void decr(int i) {incr(­ i);}
}
Une classe peut redéfinir les méthodes de sa super­classe
class CounterModulo extends Counter {
void incr(int i) {x = x + i % 2;}
}
Héritage et liaison dynamique
●
L'héritage d'implémentation est un bon moyen de réutiliser du code : une méthode héritée est partagée avec la super­classe (La liaison dynamique joue un rôle important).
class Collection {
public abstract void add(Object o);
public void addAll(Collection c) {
for(...) add(...);
}
}
class List extends Collection {
public void add(Object o) {...}
}
class Set extends Collection {
public void add(Object o) {...}
}
Compilation et exécution
●
●
Contrairement au cas des langages impératifs, un appel de méthode dans un langage à objets ne peut pas toujours être résolu à la compilation (exemple de add). Il faut donc, à l'exécution, chercher la bonne méthode, qui peut se trouver dans la classe de l'objet, ou dans une super­classe.
On peut considérer du point de vue du langage que chaque objet possède ses propres méthodes (celles­ci sont donc dupliquées autant de fois qu'il y a d'objets différents). Dans une implémentation efficace néanmoins, on ne crée qu'une seule fonction pour une classe et une méthode données, et l'objet this devient un argument supplémentaire.
Programmation logique
Programmation logique
Programmes logiques
●
Une clause de Horn est une disjonction de formules atomiques dont au plus une est positive :
–
●
Une telle formule est logiquement équivalente à :
–
●
p(f(x)) ⇐ q ∧ r(f(x), g(x, f(x)))
Et on la note en Prolog :
–
●
p(f(x)) ∨ ¬ q ∨ ¬ r(f(x), g(x, f(x)))
p(f(x)) :- q, r(f(x),g(x, f(x)))
Un programme logique est un ensemble fini de clauses de Horn.
Exemples
est_triee(cons(X, cons(Y, L))) :­ inf(X, Y), est_triee(cons(Y, L)).
est_triee(nil).
est_triee(cons(X, nil)).
Pair(0).
impair(s(X)) :­ pair(X).
pair(s(X)) :­ impair(X).
plus(X, 0, X).
plus(X, s(Y), s(Z)) :­ plus(X, Y, Z).
La négation
●
●
●
Il n'y a pas de vraie négation en prolog (impossible à définir avec des clauses de Horn).
On peut cependant y parvenir en essayant de prouver un but et en vérifiant qu'il n'y a pas de solution. C'est la négation par l'échec.
Évidemment, le prédicat de départ doit être fait pour terminer même s'il n'y a pas de solution.
Exécution
●
●
Pour exécuter un programme Prolog, on se donne un but, qui est une conjonction de formules atomiques (non closes) :
–
plus(s(0), s(s(0)), X)
–
Ou encore pair(X)
L'interpréteur retourne alors une (ou des) substitution(s) qui rend(ent) ce but prouvable (s'il en existe).
–
X = s(s(s(0)))
–
X = 0, X = 2, X = 4, ...
Sémantique déclarative
●
●
Un programme logique définit une théorie (l'ensemble des conséquences des formules du programme).
Pour un but donné, un programme logique peut boucler, ou bien s'arrêter. Dans les deux cas, il peut rendre zéro ou plusieurs substitutions.
–
Toute substitution rendue par le programme (même s'il boucle après) fait du but une conséquence de la théorie.
–
Si le programme termine, alors toutes les conséquences qui ont la forme du but ont été énumérées.
Sémantique opérationnelle
●
●
Prolog procède par résolution linéaire directe pour les clauses de Horn. C'est une méthode de preuve correcte et complète, d'où les deux propriétés de la sémantique déclarative.
Principe :
–
On commence par chercher la première clause du programme dont la tête s'unifie avec le but courant. On “applique” alors la substitution obtenue à la queue de la clause
–
On cherche alors à prouver (de gauche à droite) les prémices de cette clause (qui deviennent tour à tour le but courant).
–
Lorsqu'on est bloqué dans une impasse, on revient en arrière, pour essayer une autre clause.
Ce faisant, on construit (par les unifications successives) une substitution qui rend le but prouvable.
Intérêt et défauts
●
●
●
●
Prolog est un langage adapté à la recherche de solutions (Sudoku ?), pour faire de l'inférence de type, etc.
Les prédicats du programme jouent le rôle de fonctions, qu'on peut appeler de différentes façons : plus peut servir pour l'addition et la soustraction, selon l'instanciation des paramètres.
L'impératif s'intègre plutôt mal (car l'ordre d'évaluation est difficile à prévoir), ce qui peut poser problème pour les entrées­
sorties et l'interface avec d'autres langages.
L'absence de déclaration préalable des symboles de fonctions et de prédicats est une source importante d'erreurs (Il existe des versions typées de Prolog cependant).
Conclusion :
les défis de la programmation aujourd'hui
●
La programmation parallèle, qu'on n'a pas abordée, est souvent très délicate et suscite également à elle seule de nombreux paradigmes de programmation (passage de messages ou partage de données, etc.). Les besoins sont croissants (grappes de processeurs, processeurs à plusieurs coeurs).
Conclusion :
les défis de la programmation aujourd'hui
●
●
Le génie logiciel : programming in the large. Écrire de gros programmes pose depuis des décennies des problèmes fondamentalement différents : organisation, évolution (maintenance), réutilisation
La maîtrise de la programmation orientée objet, générique, par composants, par aspects... aide à résoudre ces problèmes.
Conclusion :
les défis de la programmation aujourd'hui
●
La sûreté de fonctionnement des logiciels est loin d'être une question résolue. Des techniques élaborées de test, d'analyse automatique, voire de preuve formelle avec un assistant, sont autant de domaines de recherches. Bien entendu, les paradigmes, et mêmes les langages de programmation utilisés influencent beaucoup les possibilités.
Un peu de lambda­calcul
●
Syntaxe du lambda­calcul (on ajoutera des parenthèses quand c'est nécessaire pour lever les ambiguïtés)
e =
| x
(identificateur)
| x.e
(lambda­abstraction)
| ee
(application)
Exemple :
x.y.(xy)
(en caml : fun x ­> fun y ­> x y)
●
Occurrences libres
Dans (x.x) x, le second x est une occurrence liée de l'identificateur x ; le troisième est une occurrence libre.
●
Remplacement
On note e[e' / x] le terme obtenu en remplaçant simultanément toutes les occurrences libres de x par e' dans e
Exemple :
(x.x)x [(y.yy) / x] = (x.x)(y.yy)
Une substitution est licite si aucune variable libre du terme e' n'est capturée par un lambda de e
Exemple :
(x.y) [x / y]
n'est pas licite.
●
Alpha­équivalence (renommage)
si y n'a pas d'occurrence libre dans e alors x.e ~ y.e[y / x]
si
e ~ e'
alors
si
f ~ f'
et e ~ e'
x.e ~ x.e'
alors
f e ~ f' e'
on prend la fermeture symétrique réflexive transitive
L'alpha­équivalence permet de renommer un identificateur, en évitant le phénomène de capture :
x.y.xy
est équivalent à x.z.xz,
mais pas à
x.x.xx
(car x a une occurrence libre dans xy)
●
Bêta­réduction
si la substitution e[e' / x] est licite
●
si
e  e' alors
x.e  x.e'
si
e  e' alors
e e''  e' e''
alors
(x.e) e'  e[e' / x]
et e'' e  e'' e'
Exemple :
((x.y.xy) (x.x)) t  (y.(x.x)y) t  (x.x)t  t
ou bien
●
(y.(x.x)y) t  (y.y)t  t
Confluence :
L'ordre de réduction ne change pas le “résultat” : il ne peut y avoir qu'une seule forme irréductible d'un lambda­terme (mais parfois certains chemins peuvent terminer et d'autres non).
●
Le lambda­terme suivant se réduit indéfiniment.
(x.xx)(x.xx)  (x.xx)(x.xx)  ...