On montre ici comment se traduiraient les particularités des évaluateurs Lisp présentés dans l'évaluateur qu'on a défini.
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 :
DCL (qui correspond aux phyla ENV et REP),ELT (c'est TRM et ATM).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 :
def a un champ DCL dont les premiers éléments sont des définitions, et dont le dernier élément est une valeur ;uti a un champ DCL qui est un environnement local d'utilisation (tous ses éléments sont donc des définitions), et l'utilisation selon le cas s'intéressera aux premiers éléments ou au dernier élément du texte nommé.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.