Comportement dynamique des textes - Le contrôle non textuel

2. Le contrôle non textuel

La manipulation symbolique des textes offre, en plus d'une facilité accrue de construction et de maintenance du programme, la possibilité de réaliser un certain nombre de contrôles non textuels : ce seront les comportements dont aucune trace ne restera visible dans le texte source du programme, et qui sont pourtant directement déduits de la texture du programme.

Pour illustrer le propos, on peut prendre l'exemple du contrôle de type ; réaliser le contrôle de type nécessite une connaissance au moins parcellaire du contexte où l'on se trouve : il faut savoir reconnaître ce qu'est l'« emploi d'une variable », il faut aussi reconnaître les déclarations de types – problèmes liés à la syntaxe du langage utilisé –, et la portée des déclarations – problème lié à la sémantique statique du langage.

Dans l'exemple qui suit, ce contrôle est réalisé dès la phase d'édition : on diminue donc la distance entre la détection d'une erreur et le moyen de la corriger.

figure a :

On déclare symboliquement les variables "A", "B" et "C" de type respectif "integer", "integer" et "real".

def var
   def decla = "VAR " (nom) ":" (type) ";" "^M"
   def util = (nom)

def varA
   def nom = "A"
   def type = "integer"
   (ref var)

def varB
   def nom = "B"
   def type = "integer"
   (ref var)

def varC
   def nom = "C"
   def type = "real"
   (ref var)

figure b :

On déclare un texte qui réalise l'affectation affect :

il est paramétré par les deux textes var1 et var2 ;
il contrôle que les textes var1 et var2 ont une "propriété" type identique – que les deux variables sont de même type.

def affect
 = (util(var1)) ":="
      (si (type(var1)) = (type(var2))
          alors
          sinon "(erreur de type)")
      (util(var2)) ";" "^M"

figure c :	1:	On utilise `affect` avec les variables `"A"` et `"B"` : aucune erreur n'est détectée.
	2:	On utilise `affect` avec les variables `"A"` et `"C"` : l'affichage signale la détection d'une erreur de type.
	3:	On utilise `affect` en oubliant un paramètre (`var2`) : l'affichage signale ici aussi la détection d'une erreur – le message pourrait être plus explicite en prévoyant le cas dans la définition de `affect` (pour la gestion des définitions partielles, cf. Chapitre 4.2, « les difficultés »).

1:  (use affect
       def var1 (ref varA)
       def var2 (ref varB))

donne
   A:=B;

1:  (use affect
       def var1 (ref varA)
       def var2 (ref varC))

donne
   A:=(erreur de type)C;

1:  (use affect
       def var1 (ref varA))

donne
   A:=(erreur de type)(util);

On notera que le système ne fait que signaler, par l'affichage, les cas d'erreur, mais ne les refuse pas. On est en effet dans la phase d'édition : nombreux seront les cas où, provisoirement au moins, on aura un texte sémantiquement incorrect, mais qui devrait être rapidement corrigé. On ne peut pas alors contraindre l'utilisateur à respecter l'ordre des déclarations que requiert le compilateur, ce qui serait inutilement pénible, et encore moins le contraindre à réaliser des modifications simultanées, surtout quand ce n'est pas possible – par exemple ici, il n'est pas possible de changer simultanément les types de "A" et "B" pour le type "real".

Des exemples autres que le contrôle de type sont plus difficiles à présenter ; plus justement, toute la sémantique statique du langage (typage, déclaration des procédures, ...) pourrait être prise en compte : je veux parler ici de contrôles de plus hauts niveaux. Il faudrait s'inspirer des outils de spécification et de validation d'algorithmes, pour réaliser des contrôles de terminaison de boucle, préservation d'invariant, initialisation des variables ...