Comportement dynamique des textes

1. Modification textuelle

2. Le contrôle non textuel

3. Insertion de code Lisp

4. Syntaxe Lisp

4. Syntaxe Lisp

On définit ici la nouvelle syntaxe de description des textes, dans laquelle apparaissent les expressions Lisp. Dans la présentation des grammaires, o na omis les parenthèses qu'impose Lisp pour faciliter la lecture.

4.1. rappel des syntaxes

On reprend les syntaxes décrites plus en détail au chapitre traitant du contexte d'évaluation (cf. Chapitre 9.1, « Contexte d'évaluation »).

syntaxe concrète

On apporte une petite modification au niveau des chaînes de caractères :

On introduit une distinction entre :
- stg : un nom,
- <string> : une chaîne de caractères,
pour plus de symétrie entre les définitions des environnements et des représentations. stg ne sera peut-être pas très utile en pratique.

syntaxe évaluée

C'est la syntaxe évaluée des textes – ou encore la syntaxe des textes évalués, c'est-à-dire la syntaxe des expressions retournées par une évaluation :

4.2. syntaxe commune

Les syntaxes non évaluée et évaluée se ressemblant beaucoup, on est conduit à les identifier, ce qui simplifie les notions introduites sans les appauvrir ni les surcharger.

On enrichit un peu la syntaxe qui se définit avant l'évaluation ; on enrichit surtout celle qui se définit après l'évaluation :

• def et ref ne sont plus des atomes (<singleton>), mais sont définis comme ils l'étaient avant l'évaluation. Ceci n'est qu'une question de point de vue : def vu comme un atome possédait quand même un champ env et un champ rep, mais qui étaient ceux de la syntaxe non évaluée ; dans la syntaxe évaluée, ces champs étaient donc non significatifs, quoique présents – puisqu'une définition est évaluée identiquement à elle-même. En confondant, syntaxiquement, les notions d'environnement ou de représentation évalués ou non évalués, on "démasque" les champs de def, ce qui ne prête pas à conséquence. Il reste qu'une définition sera toujours invariante par évaluation, et en particulier que les champs env et rep seront les formes non évaluées des champs env et rep de définition def.
  La même remarque s'applique pour ref.
  
  
• Pour les représentations, on a, syntaxiquement encore, beaucoup plus de possibilités sur la syntaxe évaluée qu'on en avait auparavant. Ici aussi c'est une question de point de vue : l'évaluation ne retournant que des chaînes de caractères (<string>) ou des représentations rep, certaines dérivations de la grammaire ne seront jamais réalisées.

Le choix de restreindre ainsi le nombre de dérivations possibles de la syntaxe évaluée sur les représentations n'est pas tout à fait innocent. On peut en effet juger qu'un emploi "transparent" des textes ne montre à l'utilisateur que les représentations évaluées : la syntaxe non évaluée et les environnements devraient être gérés automatiquement pour assurer toujours une lecture agréable du texte construit. Dans cette optique la syntaxe doit ressembler de très près à celle que reconnaît un écran Vidéo, à savoir des chaînes de caractères.

On conserve le concept de représentation rep pour un simple problème technique de tabulation : la syntaxe évaluée des représentations fournit donc bien pratiquement des suites de caractères.

4.3. syntaxe Lisp

On a repris la syntaxe précédente, en plaçant le Lisp lsp partout où on peut l'attendre :

• ni sur env, ni sur rep qui sont des listes respectivement de termes trm et d'atomes atm,
• ni sur def, ref, stg, use qui sont les "atomes" du langage,
• sur trm et atm qui sont les concepts du langage où on attend "diverses choses", sans impératif absolu.

Les deux dernières formules décrivent une expression Lisp :

Note : syntaxe Lisp des S-expressions :
S-ex ::= liste | atome
liste ::= '(' { S-ex }
atome ::= IDENT
soit :
- une S-expression est une liste ou un atome,
- un atome est un identificateur Lisp (ou une chaîne de caractères, un nombre, ...),
- une liste est : « ouvrez la parenthèse », des S-ex, « fermez la parenthèse », d'où une densité élevée de parenthèses dans les programmes Lisp.

On reprend sur les exemples précédents :

Le type humain, paramétré par le type type_sexe :

def humain
 = "TYPE " (nom) ":" "^M"
   "RECORD" "^M"
   " identif  : type_info(" (sexe) ");" "^M"
   " conjoint : type_info("
   (lsp
      (if (= (use sexe) "masculin")
          "feminin"
          "masculin")) ");" "^M"
   "END RECORD;" "^M"

Le contrôle de type sur l'affectation :

def affect
 = (util(var1)) ":="
   (lsp
      (if (= (use type(var1)) (use type(var2)))
          ()
          "(erreur de type)"))
      (util(var2)) ";" "^M"

Note :
On remarque sur les exemples que  :

• en dehors des expressions Lisp, on se dispense de préfixer une utilisation de texte par 'use', parce qu'il n'y a pas d'ambiguïté :
• à l'intérieur d'une expression Lisp, on la préfixe.

L'ambiguïté qui doit être levée dans le second cas tient à ce que, dans une expression Lisp, il est plus simple de reconnaître un des préfixes introduits ('def', 'ref', ...) que de reconnaître le nom d'une fonction Lisp (il y en a beaucoup) : de ce fait, c'est la solution simple qui a été adoptée.