La généricité

L'exemple classique de la pile comme illustration de la généricité a peut-être le tort de présenter cet aspect de la programmation comme un problème d'école, dont les applications "en vraie grandeur" sont très limitées. Pourtant la généricité des programmes est une propriété très fréquemment rencontrée. Un algorithme se présente souvent sous la forme :

sortie := accumulation(filtre(énumération(entrée)))

Par exemple :

S:=0;
for i:integer:=0 to 100 by 2 do
   S:=S+x[i];
end do;

max:=0;
repeat
   read reponse;
   if reponse>max then
      max:=reponse;
   end if;
until reponse=0;

La difficulté est que ce schéma d'algorithme peut rarement s'exprimer sous une forme fonctionnelle : l'entrée est de taille non bornée, certains traitements effectuent des effets de bord, les types retournés sont trop compliqués par rapport à ce que supporte le langage, ... C'est alors qu'on disperse la notion dans le texte du programme, parce que les outils d'expression limitent l'usage des concepts de trop haut niveau. L'éditeur structuré que l'on propose vise à pallier ces carences du langage utilisé : on utilisera les outils offerts par le langage tant que ceux-ci répondront raisonnablement aux besoins, on utilisera des "méta-outils" d'édition quand le langage ne pourra plus les satisfaire.

La généricité dans les langages souffre certainement de deux maux :

• Le premier est la lourdeur syntaxique d'expression, et la difficulté de construction des outils de mise en œuvre – analyse syntaxique, compilateur, interpréteur, ... Un concept reconnu générique est rarement complet : il nécessite la définition de paramètres de généricité, et pour chaque instanciation la définition des paramètres effectifs, ce qui multiplie le nombre de petites fonctions à contenu sémantique pauvre. De très faibles différences entre deux instances d'un même concept générique forcent le programmeur à définir un nouveau paramètre, qui rend ensuite plus délicates la compréhension des objets construits et l'évolution simultanée du modèle générique et des instances de ce modèle.
  
  
• La seconde difficulté propre à l'utilisation de la généricité provient de la manière dont est abordé le problème : la spécification syntaxique d'un module générique conduit le programmeur à appliquer une démarche descendante lors de sa conception. En effet, c'est quand le module général, attifé de tous ses paramètres, est défini complètement qu'on réalisera des instances de ce module. Or des comportements voisins ne sont pas toujours détectables ex nihilo, et sans doute faut-il aussi s'appuyer sur des formes concrètes du module générique – les instances – pour identifier les bons paramètres. L'approche présentée ici propose de voir, durant la phase d'édition, les formes instanciées des modules génériques, c'est-à-dire des formes spécifiques du fait du choix des paramètres de généricité, mais aussi des formes complètes, sur lesquelles l'utilisateur peut donc porter par simple lecture une première appréciation.

Concernant le langage LTR3, un tel éditeur introduit, en dehors du langage et donc en dehors des outils de compilation des programmes sources, le concept de généricité. De ceci découlent un certain nombre de conséquences : on introduit la notion de dérivation de type, absente du langage, et qui est une notion difficile à introduire dans un langage fortement typé ; on permet de définir des types opaques ou semi-opaques ou autres sans complications syntaxiques ; on autorise la paramétrisation par un traitement, qui est une procédure ou simplement une suite d'instructions "en ligne" ; on facilite la définition de « paramètres par défaut », qui est une notion également absente dans le langage.

Concernant l'atelier ENTREPRISE, c'est-à-dire la gestion des objets de LTR3 : on se place à un niveau plus fin de modularité ; les textes étant toujours générés en "LTR3 pur", on conserve tous les outils d'analyse syntaxique, compilation, interprétation, génération d'application, ... ; on peut construire une réelle hiérarchie de "modules" – ou plus précisément de portions de programmes écrites en LTR3 ; les liens d'utilisation sont plus précis, et donc plus souples d'emploi dans les phases de construction, mise au point et maintenance des programmes.

En conclusion, on peut remarquer que l'éditeur structuré proposé fournit, par un procédé de « macro-génération en temps réel », des textes LTR3 syntaxiquement corrects, et ne nécessite donc nullement le développement, en parallèle, d'outils qui existeraient déjà dans l'atelier ENTREPRISE.