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
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.2.1. La gestion des noms
4.2.2. Les modifications non locales sur la forme évaluée
4.2.22.1. Position du problème
4.2.22.2. Syntaxe complétée
4.2.22.3. Exemple
4.2.3. Les schémas optionnels
4.2.4. Annexe : exemple d'emploi partiel
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 modifications non locales sur la forme évaluée

1. Position du problème

2. Syntaxe complétée

3. Exemple

1. Position du problème

Comme il a été dit, un « texte » lors de son utilisation est évalué : cela signifie qu'on applique un traitement sur la définition qu'on connaît du « texte » et qu'on obtient une valeur dont on ne sait rien si ce n'est qu'elle peut être affichée à l'écran. La difficulté qui se pose alors est que certains « textes », qu'on a identifié assez naturellement, nécessitent la génération "en ligne" de texte source à deux points distincts du programme.

Par exemple, dans le cas de la pile (cf. Chapitre 2.4, « Exemple de structuration des traitements »), on a isolé le paramètre :

incrémenter-pointeur

qu'on instancie par deux valeurs, selon le choix de la structure de données :

p.b := p.b + 1

ou :

(VAR q:pile;)
NEW q;
q.b := p;
p := q;

Dans le second cas, il faut, c'est le langage qui le demande, utiliser une variable auxiliaire q pour créer une nouvelle valeur du pointeur : il faut donc aussi déclarer cette variable ; cette déclaration devra presque toujours apparaître "autre part", c'est-à-dire dans la zone des déclarations de variables, qui est une zone « textuellement » distincte de la zone des instructions.

Une "mauvaise" réponse pourrait être de placer deux utilisations du texte en paramètre :
- une utilisation dans la zone des déclarations, qui permettra la déclaration éventuelle de variables auxiliaires ;
- une utilisation en zone d'instructions, qui sera le traitement proprement dit,
D'une part alors on duplique l'information : « on utilise le texte "xxx" » ; d'autre part on place des utilisations factices en zone de déclarations, sachant que dans la majorité des cas on n'aura pas besoin de variables auxiliaires pour réaliser le traitement.

Une "bonne" réponse est de placer, à partir du point d'utilisation du traitement, la déclaration dans un « point d'accumulation » prévu à cet effet dans la forme évaluée : la chose n'est pas simple, sachant qu'on n'accède normalement pas à la forme évaluée des « textes ». C'est la "bonne" approche qui a été suivie et qu'on présente dans la suite. Elle est réalisée par la définition d'un certain nombre d'opérateurs, qui vont compliquer un peu plus la syntaxe des « textes » mais sont là pour répondre à un problème compliqué.