La gestion des noms

La première et principale difficulté qu'on rencontre concerne la gestion des noms de « textes ». Le problème se présente sous deux aspects :

• d'une part il faut trouver des noms sémantiquement significatifs, ce qui peut s'avérer complexe si l'on use pleinement de la technique de découpage d'un source en « textes » ;
• d'autre part le système ne peut guère supporter une utilisation anarchique des symboles : une certaine discipline s'impose.

Le premier point est un problème général, à résoudre au cas par cas selon la "sensibilité" de chacun. Le second est en revanche plus embarrassant, parce que le respect d'une discipline est toujours astreignant et qu'il sous-entend que le programme construit est assez fragile – cette fragilité se révélerait par un non respect de la discipline.

1. Fragilité des programmes

2. Perte de branches de l'« arbre des textes »

3. Paramètres effectifs

4. « effets de bord »

3. Paramètres effectifs

Le passage des paramètres effectifs n'est pas explicite : c'est un « effet de bord » du mécanisme d'empilement des environnements d'appel. L'instanciation du paramètre formel n'étant effective qu'à l'"extrême limite", il peut advenir qu'une autre définition du même symbole masque celle du paramètre effectif.

Par exemple, le schéma des fonctions est :

(def fonction
   ... NOM TYP ... INSTR ...
   (def nom () ((use NOM)))
   ...)

(on a les paramètres formels NOM, TYP, ..., INSTR ; on a une propriété : nom, qui utilise simplement le paramètre NOM). Une déclaration de fonction :

(def fct-1
   ((ref fonction)
    (def NOM () ("fct-1"))
    (def TYP () ("integer"))
    ...
    (def INSTR ...)))

fct-1 fait référence au modèle des fonctions, en instanciant les paramètres formels NOM, TYP, ..., INSTR. Dans ce cas, l'instruction INSTR pourra effectivement utiliser la propriété nom du modèle fonction : en effet le paramètre utilisé s'appelle NOM, un symbole bien trop "commun" pour ne pas être redéfini par INSTR.

Plusieurs solutions sont possibles :

• On peut utiliser les « opérateurs typés »: deft, uset, reft, en donnant au symbole du « type » une valeur distinctive. Par exemple :

  (def fct-1
     ((ref fonction)
      (deft bloc-fct NOM () ("fct-1"))
      (deft bloc-fct TYP () ("integer"))
      ...
      (deft bloc-fct INSTR ...)))
  

  La propriété nom de fonction utilise alors le paramètre « typé » NOM :

  (def nom () ((uset bloc-fct NOM)))

• Une autre solution voisine est de "typer" les textes en les plaçant sous un texte de nom distinctif. Par exemple :

  (def fct-1
     ((ref fonction)
      (def bloc-fct
         ((def NOM () ("fct-1"))
          (def TYP () ("integer"))
          ...
          (deft bloc-fct INSTR ...)))))
  

  La propriété nom de fonction utilise alors le paramètre "typé" NOM :

  (def nom () ((use NOM ((bloc-fct)))))

  On rattache alors l'utilisation de nom au texte bloc-fct, ce qui fournit pour nom la bonne définition.

  On peut noter que les deux approches repoussent d'un cran le problème : le nom bloc-fct pourrait lui-même être surchargé, auquel cas on ne retrouverait peut-être pas la bonne définition du paramètre effectif.

• Une autre solution encore est d'introduire un nouvel opérateur : defevl, qui force l'évaluation de ses arguments (environnement et représentation). On redéfinit alors la propriété :

  (defevl nom () ((use NOM)))

  qui, dès l'évaluation de la référence à fonction, fournirait la forme évaluée :

  (def nom () "fct-1")

  (dans le cas courant de def, les arguments ne sont pas évalués). On supprime alors la difficulté de retrouver, à l'évaluation d'un paramètre formel, le paramètre effectif qu'on souhaitait lui voir attaché. Cette dernière solution a cependant les inconvénients :

  • d'introduire une autre sorte de définition (la définition évaluée defevl), ce qui fait perdre en homogénéité des concepts ;
  • d'interdire, dans la définition évaluée, l'emploi de variables libres : la définition est évaluée dans son contexte de définition – un peu enrichi – et non plus dans le contexte d'utilisation.