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

7. La réponse au problème

Par rapport au problème initial – la répétition de texte – on peut juger qu'on n'a fourni qu'une réponse partielle. En effet il peut exister des liens sémantiques entre deux éléments différents d'un programme, c'est-à-dire deux éléments qui n'ont pas le même schéma de décompilation. Un exemple typique est la variable et son type ; les deux objets sont différents à tout point de vue (en particulier ils ne sont pas reconnus par le même identificateur) et pourtant on ne saurait utiliser une variable en en ignorant le type.

Il est alors nécessaire d'introduire la possibilité de déclarer des définitions groupées. Une idée simple consiste à proposer un constructeur de structure ("record") grâce auquel on accède aux divers aspects d'un même concept – ses « propriétés » – au travers des champs de la structure. Par exemple une variable est une structure à deux champs : le champ « nom » et le champ « type » ; on accède au nom d'une variable « var » par « var.nom » et à son type par « var.type ». On peut trouver à ce choix un défaut majeur qui est qu'on perd la vision uniforme des objets manipulés ; on a en effet dans ce cas deux types d'objets : les opérateurs simples et les structures.

Dans l'optique d'uniformiser les concepts, on modifie alors légèrement la notion de « structure » : il s'agit toujours d'une liste de champs, la différence étant qu'un champ de la structure ne définit pas une « zone mémoire » de la structure de données mais une fonction. Accéder à un champ de l'objet du type « structure » c'est d'abord accéder à l'une des fonctions applicables sur cet objet. Si l'on veut maintenant définir une « zone mémoire » sur cet objet, il faut définir deux champs : un champ de lecture de la « zone » et un champ de mise à jour (écriture) de cette « zone » ; il faut ensuite définir un « point d'accumulation » des données qui conserve la valeur persistante du champ : ce « point » n'est pas accessible de l'utilisateur.