L'outil présenté est un éditeur à références concentrées. Le but poursuivi est de concentrer en un unique endroit tout choix de réalisation opéré à l'écriture d'un texte de programme.
A un premier niveau d'utilisation, le schéma est :
Par ce mécanisme, on peut paramétrer un texte par n'importe quel constituant du langage (ici : un type, bien que LTR3 ne soit pas un langage générique).
On a en plus la vision complète de l'objet réalisé : si l'on définit une pile de réels, on ne lira pas dans le texte source :
« pile de "element" ; "element" = "real" »
mais directement
« pile de "real" »
Ainsi la paramétrisation n'affecte pas la facilité de lecture puisque c'est l'objet final qu'on lit sous l'éditeur.
La première conséquence est alors qu'il faut, dans l'éditeur, définir la notion de « zone d'affichage en lecture seulement ». En effet, à un endroit ou apparaît "real" dans l'exemple précédent il ne faut pas avoir la possibilité de modifier le terme : autrement ce sont toutes les occurences de "real" qui seraient simultanément modifiées – c'est bien dans ce cas le « fichier principal » et non pas le « fichier paramètre » que l'on modifie.
La deuxième conséquence, réciproque de la précédente, est que l'éditeur doit offrir un confort suffisant pour déclarer une certaine zone de texte comme « zone d'affichage en lecture seulement ». Ainsi, pour passer d'une première rédaction de la pile comme :
« pile-de-réels »
à une deuxième :
« pile-paramétrée-par-le-type-élément ; élément = réel »
on n'a pas à réécrire la portion de programme qui définit la pile générique mais simplement à indiquer sous l'éditeur où sont les zones faisant référence à un même paramètre (ici : "réel").
Ceci est certainement avantageux, car il est à mon sens plus facile de définir un modèle générique par l'exemple :
- on construit un premier objet ;
- on identifie ce qui correspond à des paramètres de l'objet ;
- on construit le type paramétré, en réalisant alors l'objet comme une instance de ce type.
Au deuxième niveau, on peut considérer les objets sous la forme d'une arborescence :
(pile de réels ; de taille 100)
puis de graphe :
(le type des éléments de la pile est indéfini ;
la taille des piles est toujours 100)
On peut remarquer que ce mécanisme permet, en corrolaire, la construction d'un éditeur syntaxique. Il suffit pour cela de définir toutes les structures syntaxiques du langage utilisé sous forme de type paramétré :
Note :
Chaque utilisation d'identificateur pourrait également être concentrée (a, b, delta, ...), mais le dessin deviendrait trop confus.
On notera que le dessin deviendrait trop confus mais non le texte. En effet, la décomposition syntaxique est forcément arborescente ; l'utilisation d'identificateurs en zone concentrée consiste en une redirection de la valeur du nœud vers une référence commune et ne constitue donc pas un élément de l'arbre syntaxique ; c'est simplement un autre découpage du texte, selon une autre approche.
Un dernier point concerne les commentaires informels attachés au programme : ceux-ci peuvent également se référer à des zones concentrées du texte source, la cohérence entre les commentaires et le programme est ainsi mieux réalisée.