Définition de propriétés

Dans les exemples précédents, on peut juger que les choix de définition des opérateurs de la grammaire contraignent à l'écriture de programmes "très proches" du langage. Par exemple l'appel d'une fonction correspond à l'utilisation de l'opérateur call-fct et la donnée de paramètres ; le programme appelant connaît donc la nature syntaxique de l'élément appelé, alors qu'il n'y en a pas vraiment la nécessité.

On s'est déjà un peu extrait des spécificités du langage pour les variables :

• dans sa définition, une variable est un NOM, un TYP, éventuellement une valeur INIT ;
• dans son utilisation c'est lect, ecr, ou init, qui sont des propriétés indépendantes de la définition « textuelle » d'une variable.

On peut étendre la démarche aux fonctions :

• dans sa définition, une fonction est un certain nombre de paramètres, et un certain schéma de déclaration de fonction ;
• dans son utilisation c'est l'élaboration d'une valeur (à rapprocher de la propriété lect des variables), avec la définition d'un paramètre effectif.

Au lieu d'appeler une fonction "en le disant explicitement" :

(def EXP
   ((def BLOC-FCT
       ((bloc-fct((feuille)))))
    (def EXP ...))
   ((call-fct)))

on utilise le texte appelé, par sa propriété d'« utilisation » :

(def EXP
   ((def EXP ...))
   ((feuille)))

Par ce schéma, on ignore alors quel choix de représentation a été fait pour le concept « feuille ». L'"appel" pourra fournir :

feuille(a) ou a.feuille

selon la nature de la propriété d'« utilisation » du texte feuille.

La difficulté à masquer des définitions de texte conduit à introduire une barrière de visibilité à la définition d'une fonction. Par exemple, on définit :

(def compte
   ((def util () ((call-fct)))
    (def private ...))
   ((call-fct)))

Le texte compte offre les deux propriétés :

• util : l'utilisation de la fonction,
• private : une propriété que, « conventionnellement », on n'utilise pas – cette propriété n'est utile que pour la déclaration de variables de bloc.

Dans sa partie privée, il définit la fonction :

(def private
   ((decl-fonction)
    (def bloc-fct
       ((def NOM ...)
        ...
        (def INSTR ...))))
   ((decl-fonction)))

Le schéma général de définition d'une fonction est donc :

compte = fonction
      -> util = ...
         private
            -> decl-fonction
               bloc-fct
                  -> NOM = ...
                     ...
                     INSTR = ...

Il est relativement simple : il s'agit d'un arbre de profondeur 2. Mais si l'on demande à l'utilisateur de construire et de maintenir lui-même cet arbre, alors il se révèlera certainement complexe – ou tout du moins pénible d'emploi. Il faudrait donc offrir à l'utilisateur un moyen d'exprimer en des termes simples des schémas de traitements pour le parcours ou la modification de l'arbre des textes. Il lui permettrait par exemple de se positionner directement sur les éléments significatifs de l'arbre – ici le premier élément significatif est le champ NOM ; tout ce qui précède répond au modèle de définition d'une fonction, mais ne l'intéresse pas.