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
6.1. Les critères
6.2. Le classement
6.3. La structure Plate
6.31. La nature d'Objet : les éditeurs classiques
6.32. La nature de Type : la macro-génération
6.33. La nature de Classe
6.4. La nature d'Objet structuré
6.5. La nature de Type structuré
6.6. La nature de Classe structurée
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

La structure Plate

1. La nature d'Objet : les éditeurs classiques

2. La nature de Type : la macro-génération

3. La nature de Classe

3. La nature de Classe

nature de Classe - structure Plate

On propose deux exemples qui satisfont aux critères de Classes-Plates :

Classe : on a un usage dynamique des modèles.

Plat : on reste dans un domaine non structuré.

Le système EBE (« Editing by Example, [Nix 85]) permet de définir dynamiquement par la donnée de quelques exemples, des schémas de transformation de texte ; par exemple, ayant la connaissance des transformations :

@i[O.K.] → {\s1 O.K.}
@i[Boston Morning Post] → {\s1 Boston Morning Post}

le système déduit, par unification, la règle de transformation :

@i[-1-] → {\s1 -1-}

(-1- est le paramètre de la macro-définition). On définit donc un dictionnaire de symboles, plus riche que ceux qu'on trouve ailleurs qui sont généralement des macro-définitions sans paramètres. On peut de plus traiter un texte existant simplement en indiquant quelques exemples de transformation pris au sein du texte.

Un autre exemple est le langage ABF [HES 87] : le système aide à la construction de documents juridiques, où l'aspect répétitif et systématique est particulièrement important. L'originalité de l'approche réside dans la simplicité de la représentation des "modules" – en l'occurrence du texte en anglais. L'utilisateur, qu'on suppose ne pas être informaticien, accède directement à la Représentation Interne, ce qui offre une grande souplesse dans la définition des paramètres des "modules". De plus, la forme interprétée des "modules" est rendue dans le même format que le format d'entrée, ce qui permet d'élaborer progressivement le texte final par des évaluations successives des "modules".

ABF a davantage une nature de Classe que de Type parce que l'utilisateur accède directement à la Représentation Interne – l'accès est filtré par le système qui transforme l'appel d'une macro-définition en une question intelligible par un non-informaticien – et que la forme évaluée (macro-expansée) peut à nouveau être traitée par ABF.