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.3.1. Présentation générale
2.3.2. Présentation détaillée
2.3.3. Première étape : le modèle générique
2.3.33.1. Les structures de données
2.3.33.2. Les contextes d'utilisation
2.3.33.3. Les traitements simples
2.3.33.4. Les traitements complexes
2.3.4. Deuxième étape : les nouveaux cas
2.3.5. Annexe 1 : exemple d'évaluation
2.3.6. Annexe 2 : les procédures de recherche
2.3.7. Annexe 3 : la représentation textuelle
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

Première étape : le modèle générique

Dans cette première étape, on ne retient que les deux premiers types de structures de données : [1] et [2]. Reconnaissant, malgré la distance entre ces deux types, qu'on va devoir écrire deux fois le même "genre" de modules, on peut souhaiter paramétrer un module générique unique puis instancier chaque cas avec ses particularités.

1. Les structures de données

2. Les contextes d'utilisation

3. Les traitements simples

4. Les traitements complexes

2. Les contextes d'utilisation

Puisqu'on a deux types de structures, on a deux contextes d'utilisation du schéma-type comm.

Premier cas :

(def ctx1
   ((def NOM () ("1"))
    (def RANG
       ((def RGPHY () ("H"))
        (def CONV-RGLOG () ("RG1({RGLOG})"))
        (def NUM-LOG () ("1"))
        (ref fic ((comm)))))
    (def OBJ
       ((def val () ("X1"))
        (def aux () ("Y1"))))))

Deuxième cas :

(def ctx2
   ((def NOM () ("2"))
    (def RANG
       ((def CONV-RGLOG () ("TX2({RGLOG})"))
        (ref tab ((comm)))))
    (def OBJ
       ((def val () ("X2"))
        (def aux () ("Y2"))))))

Le contexte ctx1 présente trois champs :

NOM : donne un nom à ce contexte (ici : 1)
RANG : définit les propriétés applicables dans le contexte, par référence au schéma des fichiers (fic)
OBJ : définit les objets sur lesquels portent ces propriétés (val = variable courante ; aux = variable auxiliaire)

Du fait de l'instanciation partielle des paramètres de fic, depuis ctx1 on "voit" les propriétés :

RANG :
lect
  ("H=RG1({RGLOG})

 ; 

RGPHY = "H"
  
CONV-RGLOG = "RG1({RGLOG})"
    SEARCH=1,H:{VAL}") ; NUM-LOG = "1"  RGPHY = "H"
ecr
  ("H=RG1({RGLOG})

 ; 

idem
    MODIF=1,H:{VAL}") 
ins
  ("H=RG1({RGLOG})

 ; 

idem
    INSERT=1,H:{VAL}") 
supp
  ("H=RG1({RGLOG})

 ; 

idem
    DELETE=1,H") 

On peut noter par exemple que l'instanciation de CONV-RGLOG introduit un nouveau paramètre RGLOG, et que la "non-instanciation" du paramètre VAL fait qu'on conserve ce paramètre.

De la même façon, ctx2 présente les propriétés :

NOM
RANG :
lect
  ("{VAL}=TX2({RGLOG})")

 ; 

VAL-RGLOG = "TX2({RGLOG})"
ecr
  ("TX2({RGLOG})={VAL}")

 ; 

idem
OBJ