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.4.1. Qualités d'un langage
5.4.2. La traduction pour « Moi aussi »
5.4.22.1. La fermeture lexicale
5.4.22.2. La liaison dynamique
5.4.22.3. Les environnements comme objets de première classe
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

La traduction pour « Moi aussi »

On montre ici comment se traduiraient les particularités des évaluateurs Lisp présentés dans l'évaluateur qu'on a défini.

1. La fermeture lexicale

2. La liaison dynamique

3. Les environnements comme objets de première classe

3. Les environnements comme objets de première classe

La distinction qu'on introduit, dès le départ, entre l'environnement et la représentation d'un texte, a pour conséquence qu'on ne peut considérer les environnements comme des objets de première classe.

Pour ce faire, il faudrait appauvrir la syntaxe initiale, en ne définissant que deux phyla :

La syntaxe initiale s'écrit alors :

(1)DCL ::= dcl
(2)    dcl -> ELT*...
(3)ELT ::= DCL LSP def uti STRING
(4)    def -> NOM DCL
(5)    uti -> NOM DCL
(11)LSP ::= lsp
(12)    lsp -> SEX*...
(13)SEX ::= ELT ATOME LISTE

Le problème est alors de bien interpréter un opérateur :

Par exemple, le texte :

(def txt
   (dcl
      (def a (dcl "A"))
      (def b (dcl "B"))
      (dcl (uti a) "," (uti b))))

doit être compris comme :
- un texte qui définit localement les textes a et b,
- et dont la valeur d'utilisation est : (dcl (uti a) "," (uti b)).

En particulier, s'intéresser à la valeur d'un texte, c'est forcer l'évaluation du dernier élément, par une fonction explicitement nommée, par exemple alast :
(alast (uti txt))

L'inconvénient qu'on peut trouver à une telle simplification est qu'elle paraît fragiliser le système : une "mauvaise interprétation" d'un texte conduit à des cas qui n'ont intuitivement pas de sens, et auxquels justement on ne pourra pas donner de sémantique précise. Le choix retenu a été de typer les valeurs d'environnement et de représentation en distinguant les phyla ENV et REP, ce qui ramène d'une façon assez simple les cas qui ont une sémantique imprécise à des cas d'erreur de type.