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.1.1. Les intentions
2.1.11.1. L'objectif
2.1.11.2. La réponse
2.1.11.3. L'éditeur syntaxique
2.1.11.4. L'état de la science dans le domaine
2.1.11.5. L'expression de besoin
2.1.11.6. Le choix de la Représentation Interne
2.1.11.7. La réponse au problème
2.1.11.8. La référence
2.1.2. Eléments du langage
2.2. Notations
2.3. Exemple de structuration des données
2.4. Exemple de structuration des traitements
2.5. Exemple de structurations connexes
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

Les intentions

1. L'objectif

2. La réponse

3. L'éditeur syntaxique

4. L'état de la science dans le domaine

5. L'expression de besoin

6. Le choix de la Représentation Interne

7. La réponse au problème

8. La référence

5. L'expression de besoin

On retient l'idée de la définition d'opérateurs. La contrainte qu'on s'impose est alors qu'étant placé sur un nœud de l'arbre syntaxique en cours d'édition on puisse définir un nouvel opérateur, dont le schéma de décompilation sera le texte associé au sous-arbre attaché à ce nœud et dont les paramètres seront l'ensemble des nœuds non encore instanciés de ce sous-arbre. Ceci se rattache directement à la notion de méta-variable telle qu'on la trouve classiquement dans un éditeur syntaxique ; la différence est qu'on ne considère pas ici ce concept comme appartenant à l'éditeur – et ayant de ce fait une durée de vie limitée au temps de la session sous l'éditeur – mais qu'on le considère comme attaché au tampon (« buffer ») en cours d'édition : il sera donc conservé dans la Représentation Interne (R.I.) de ce tampon au même titre que les diverses instances d'opérateurs qui le composent.

Pour les opérateurs de liste, il faudra pouvoir définir un nouvel opérateur qui ne retienne qu'une partie de cette liste. Par exemple, il pourra s'agir de deux instructions. A un niveau de détail plus fin, considérant qu'un identificateur est une liste de caractères, il s'agira alors d'un certain nombre de caractères consécutifs.

Au cœur du problème se pose le choix de la R.I. L'éditeur qui va manipuler cette R.I. doit en effet avoir une vision uniforme de deux aspects bien distincts du programme :

En effet, toute zone cohérente d'un tampon d'édition (c'est-à-dire toute zone qui ne chevauche pas deux branches distinctes de l'arbre syntaxique) peut être vue soit comme une zone du tampon soit comme l'instance d'un nouvel opérateur. Le passage de l'une à l'autre de ces deux visions doit être le plus aisé possible.