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.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
7.1. Où se situe-t-on ?
7.2. Vers quoi tend-on ?
7.3. L'éditeur à références déductives
7.4. L'éditeur à références constructives
7.5. Les Problèmes – et les Réponses
7.51. L'éditeur à références concentrées
7.52. L'éditeur à références déductives
7.53. L'éditeur à références constructives
7.6. L'état des travaux
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 Problèmes – et les Réponses

1. L'éditeur à références concentrées

2. L'éditeur à références déductives

3. L'éditeur à références constructives

3. L'éditeur à références constructives

Problème 3.1 : personnalisation des programmes

La possibilité de symboliquement représenter des zones de programme fait largement appel à la "sensibilité" du programmeur ; ceci signifie qu'on risque d'obtenir des textes symboliquement représentés par des conventions très personnelles et difficiles à partager entre plusieurs utilisateurs.

Réponse 3.1.a : rendre les programmes anonymes

La solution pauvre, et simple à réaliser, consiste à toujours autoriser la lecture du texte réel – celui qui sera construit en dernier ressort – ignorant ainsi l'expression symbolique définie antérieurement par le programmeur.

Réponse 3.1.b : langage universel

La solution riche serait de définir un jeu de règles et de contraintes pour un standard de présentation des programmes qui serait commun :
- à tous les langages,
- à tous les domaines.
L'objectif serait certainement très ambitieux, mais peut-être aussi trop ambitieux.