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

1. Présentation générale

L'analyse du problème conduit à décomposer le programme en deux niveaux :

décomposition du programme

L'implantation présentée diffère légèrement de celle qu'on trouve formellement définie dans la partie Technique (cf. ibid.) : on n'introduit pas de matrice des phyla, et à chaque phylum on attache alors la liste des phyla pères. Ceci permet de n'avoir qu'une seule structure de données, ce qui simplifie la présentation.

Note :
Relativement au coût des algorithmes, on perd en efficacité sur la fonction ascendance : celle-ci construit l'ascendance d'un phylum donné en parcourant le graphe comme s'il s'agissait d'un arbre. Elle passera donc plusieurs fois sur les mêmes nœuds si deux chemins différents y conduisent.

Pour la syntaxe initiale, la seule situation où on passe deux fois sur un même nœud est celle (1) où le nœud d'origine est le phylum LSP et (2) où le nœud doublement visité est le phylum SEX. Du fait de la faible connexité du graphe, l'algorithme en pratique est donc plus efficace – quoiqu'en théorie il le soit moins.