“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 46 — #56
i
i
i
i
i
i
i
i
46
2
• La programmation déclarative
x
1
2
3 nil
x 1
Dans la mémoire
"X"
"Y"
2
Figure 2.15 La mémoire après le lien d’une des variables.
2.2.8 Les variables dataflow
Dans le modèle déclaratif, la création et le lien d’une variable se font séparément. Que
se passe-t-il si on essaie d’utiliser une variable avant qu’elle soit liée ? C’est une erreur
d’utilisation de variable. Certains langages font la création et le lien des variables
en une fois, ce qui élimine ces erreurs. C’est le cas pour les langages fonctionnels.
D’autres langages permettent la séparation de la création et du lien. Voici ce qui se
passe dans quelques langages quand il y a une erreur d’utilisation :
1. L’exécution continue sans message d’erreur. Le contenu de la variable n’est pas
définie, son contenu est « n’importe quoi » : ce que l’on trouve dans la mémoire
à l’adresse de la variable. C’est ce que fait le langage C++.
2. L’exécution continue sans message d’erreur. La variable est initialisée à une
valeur par défaut quand elle est déclarée, par exemple, à 0 pour un entier. C’est
ce que fait le langage Java pour les champs dans les objets et les structures de
données, comme les tableaux (« arrays »). La valeur par défaut dépend du type.
3. L’exécution s’arrête avec un message d’erreur (ou une exception est levée). C’est
ce que fait le langage Prolog pour les opérations arithmétiques.
4. L’exécution n’est pas possible parce que le compilateur détecte qu’il y a un
chemin d’exécution qui mène à l’utilisation de la variable sans l’avoir initialisée.
C’est ce que fait Java pour les variables locales.
5. L’exécution attend jusqu’à ce que la variable soit liée et continue ensuite. C’est
ce que fait Oz, pour soutenir la programmation dataflow.
Ces cas sont énumérés dans l’ordre du plus mauvais au meilleur. Le premier cas est
très mauvais car chaque exécution d’un programme peut donner un résultat différent
(le non-déterminisme). Par ailleurs, comme l’existence de l’erreur n’est pas signalée,
le programmeur n’est même pas conscient du problème. Le deuxième cas est un peu
mieux. Si le programme présente une erreur d’utilisation, au moins il donnera toujours
le même résultat, mais le résultat peut être faux. De nouveau, le programmeur n’est
pas mis au courant du problème.
i
i
i
i
i
i
i
i
46
2
• La programmation déclarative
x
1
2
3 nil
x 1
Dans la mémoire
"X"
"Y"
2
Figure 2.15 La mémoire après le lien d’une des variables.
2.2.8 Les variables dataflow
Dans le modèle déclaratif, la création et le lien d’une variable se font séparément. Que
se passe-t-il si on essaie d’utiliser une variable avant qu’elle soit liée ? C’est une erreur
d’utilisation de variable. Certains langages font la création et le lien des variables
en une fois, ce qui élimine ces erreurs. C’est le cas pour les langages fonctionnels.
D’autres langages permettent la séparation de la création et du lien. Voici ce qui se
passe dans quelques langages quand il y a une erreur d’utilisation :
1. L’exécution continue sans message d’erreur. Le contenu de la variable n’est pas
définie, son contenu est « n’importe quoi » : ce que l’on trouve dans la mémoire
à l’adresse de la variable. C’est ce que fait le langage C++.
2. L’exécution continue sans message d’erreur. La variable est initialisée à une
valeur par défaut quand elle est déclarée, par exemple, à 0 pour un entier. C’est
ce que fait le langage Java pour les champs dans les objets et les structures de
données, comme les tableaux (« arrays »). La valeur par défaut dépend du type.
3. L’exécution s’arrête avec un message d’erreur (ou une exception est levée). C’est
ce que fait le langage Prolog pour les opérations arithmétiques.
4. L’exécution n’est pas possible parce que le compilateur détecte qu’il y a un
chemin d’exécution qui mène à l’utilisation de la variable sans l’avoir initialisée.
C’est ce que fait Java pour les variables locales.
5. L’exécution attend jusqu’à ce que la variable soit liée et continue ensuite. C’est
ce que fait Oz, pour soutenir la programmation dataflow.
Ces cas sont énumérés dans l’ordre du plus mauvais au meilleur. Le premier cas est
très mauvais car chaque exécution d’un programme peut donner un résultat différent
(le non-déterminisme). Par ailleurs, comme l’existence de l’erreur n’est pas signalée,
le programmeur n’est même pas conscient du problème. Le deuxième cas est un peu
mieux. Si le programme présente une erreur d’utilisation, au moins il donnera toujours
le même résultat, mais le résultat peut être faux. De nouveau, le programmeur n’est
pas mis au courant du problème.