afficher >><< masquer ]
SAMPI - Editeur structuré
1. Le Problème et la Proposition
2. Le Langage Primitif de Représentation Textuelle
2.1. Présentation de la Syntaxe Concrète
2.2. Notations
2.3. Exemple de structuration des données
2.4. Exemple de structuration des traitements
2.5. Exemple de structurations connexes
2.5.1. Présentation
2.5.11.1. Présentation générale
2.5.11.2. Les données
2.5.11.3. Les traitements
2.5.2. La macro-génération
2.5.3. Les symétries du programme
2.5.4. Annexe 1 : Construction du champ CHP_PRESENT
2.5.5. Annexe 2 : Les fonctions de traitement en Lisp
3. Le Langage Complété pour la Structuration des Textes
3.1. Présentation de la Syntaxe Complétée
3.2. Etude quantitative de l'évolution des programmes
3.3. L'édition syntaxique
3.4. étude de cas : le langage LTR3 et l'atelier ENTREPRISE
4. L'Enrichissement du Langage par de Nouveaux Concepts
4.1. Présentation de la Syntaxe Abstraite
4.2. Les difficultés
4.3. Compléter la Syntaxe
5. La Formalisation des Solutions Techniques
5.1. L'évaluation fonctionnelle
5.2. La structuration par les objets
5.3. Modèle sémantique comparé de l'évaluateur
5.4. Comparaison critique
5.5. Construction de la Syntaxe Abstraite
6. Les Comparaisons avec d'autres Approches
7. Les Perspectives
8. Les Editeurs
8.0. brisé sur la barrière de la complexité (une fois de plus)
8.1. L'éditeur ligne : Manuel de l'utilisateur
8.2. L'éditeur page : Guide de l'utilisateur
9. Les Aspects d'Implantation
9.1. Contexte d'évaluation
9.2. La Syntaxe Abstraite : Manuel du concepteur
9.3. L'éditeur page : Guide de l'implanteur
Références
Rubrique Perl-Javascript

Présentation

L'exemple qu'on traite est le programme Lisp qui implante les fonctions de modification incrémentale de la syntaxe abstraite (cf. Chapitre 5.5, « Construction de la Syntaxe Abstraite »). Deux remarques s'imposent :

Je ne pense pas qu'il faille en conclure que l'exemple est mal choisi : on n'a pas toujours de répétition dans le texte source d'un programme ; mais quand on en a, et c'est le cas spécialement dans les parties algorithmiques, il me semble intéressant de les mettre en relief. C'est la situation dans laquelle on se place.

Pour terminer ce préambule, je voudrais juste signaler que le programme n'a pas été remanié pour étayer l'argumentation. S'il présente de nombreuses symétries c'est parce qu'elles se sont imposées d'une façon naturelle à la rédaction du programme.

1. Présentation générale

2. Les données

3. Les traitements

3. Les traitements

On morcelle les traitements pour en faciliter la réalisation :

graphe d'appel
graphe d'appel

les « fonctions utilisateur »

put = putphyl, putoper, putoperphyl, putperephyl, putfilsphyl
rem = remphyl, remoper, remoperphyl, remperephyl, remfilsphyl
get = getphyl, getoper, getoperphyl, getperephyl, getfilsphyl
Elles font le lien entre l'utilisateur qui nomme les objets (phylum ou opérateur) et les objets eux-mêmes (contrôles de définition ; contrôles de non redéfinition).

les fonctions de traitement

*put = *putphyl, *putoper, *putoperphyl, *putperephyl
*rem = *remphyl, *remoper, *remoperphyl, *remperephyl
Elles réalisent les traitements sur les objets (phylum ou opérateur).

les fonctions d'erreur

ERR = CONTROLE-def, CONTROLE-indef, ERREUR
Elles filtrent les cas d'erreur.

les fonctions auxiliaires

ascendance
*ins = *insereoperphyl
*sup = *supprimeoperphyl
Elles correspondent à un « regroupement de code » – le traitement étant effectué à plusieurs points distincts du programme, on définit une fonction.

le module générique

liste = recherche, ins, sup
Elles définissent la structure générique des listes :
recherche : recherche d'un élément de la liste d'après son nom
ins : insertion d'un élément dans la liste
sup : suppression d'un élément de la liste
Le module est paramétré par la fonction nom (le nom d'un élément de la liste).