La macro-génération

La macro-génération est une technique « vieille comme le monde », à la fois largement utilisée et largement critiquée. On l'utilise dans deux optiques :

• Dans un souci d'efficacité : la génération de "code en ligne" est la plus simple des techniques d'optimisation. A l'interprétation d'un programme Lisp, on aimera bien ne pas trop attendre ; pour la compilation, on aimera éviter les appels incompilables à la fonction eval.
• Dans un souci d'abstraction : on exprime le problème dans ses termes, et on génère du code dans les termes du langage. Dans un langage comme COBOL, où l'on cherche à écrire un programme comme on écrirait un texte en anglais, la technique est presque un concept primitif du langage.

Le gros avantage de la macro-génération en est sa simplicité. Mais cette simplicité ne doit pas masquer certains dangers qui lui sont liés :

• On ne contrôle plus la taille du code généré : même si l'on tient compte de l'augmentation régulière de la puissance des ordinateurs, il faut malgré tout rester dans des limites raisonnables.
• On ne connaît pas a priori l'allure du code généré : la macro-génération peut construire un code totalement aberrant, ou subtilement aberrant ; par exemple en C, la macro-définition :
  #define max1(a,b) ((a<b)? (b):(a))
  offre toutes les garanties qu'on ne retrouverait pas dans la suivante :
  #define max1(a,b) ((a<b)? b:a)
  les deux définitions sont pourtant syntaxiquement très voisines.

On trouve dans [KoW 87] une syntaxe pour les macro-définitions en Lisp qui cherche à en faciliter la compréhension : au lieu de proposer classiquement une fonction qui permette de tester sur quelques exemples la macro-génération, on propose un moyen d'expression qui fait ressembler la macro-définition à sa forme macro-générée. Dans [TrY 80] on cherche à réduire l'initiative laissée au programmeur à l'utilisation d'une macro-définition (COBOL) : c'est la macro-définition syntaxique, où les paramètres effectifs doivent répondre à certaines contraintes d'ordre syntaxique qu'on impose à la définition.

1. Les données

2. Les traitements

2. Les traitements

On regarde ici la première fonction "intéressante" : *putphyl :

(de *putphyl (nomphyl attphyl)
   (let ((phyl (makephyl nomphyl attphyl)))
        (ins phylt phyl)
        (mapv '(lambda (oper)
                  (let ((drap (makedrap)))
                       (ins (phyloper oper) drap)
                       (ins (operphyl phyl) drap)))
              opert))
   (*putphyl-ana nomphyl attphyl))

On retrouve dans cette fonction les principales facultés d'abstraction du langage Lisp :

• occurrence de variables libres phylt et opert : elles permettent de réaliser les « effets de bord » ;
• utilisation des propriétés des objets de « bas niveau » : makephyl, phyloper, ... ; on nomme la propriété sans savoir quelle est son implantation – il s'agit peut-être de l'appel d'un traitement, peut-être aussi d'un accès (macro-généré) à un élément de la structure de données ;
• utilisation de fonctions génériques, ici ins : parce que le langage est a-typé, la définition d'une fonction générique est particulièrement simple (et particulièrement peu contrôlée aussi) ;
• appel d'un traitement sur un paramètre fonctionnel : mapv sur la lambda-expression.

Les premiers points illustrent les possibilités d'abstraction de données du langage ; le dernier point concerne les traitements : c'est celui-là qu'on regarde maintenant.

2.1. dérivation de la fonction mapv

Mapv n'est pas (dans LeLisp V15.2) une fonction prédéfinie. C'est l'application de mapc (prédéfinie) sur le type liste – les listes pour lesquelles le premier élément n'est pas significatif. Ceci suggère évidemment l'emploi d'une macro-définition

(mapv fct ref1 ... refN)
; donne :
(mapc fct (cdr ref1) ... (cdr refN))

De même si mapc n'était pas prédéfinie, on introduirait la macro-définition :

(mapc fct lst1 ... lstN)
; donne :
(let ((aux1 lst1) ... (auxN lstN))
     (while (and aux1 ... auxN)
            (fct (nextl aux1) ... (nextl auxN))))

On pourrait ensuite affiner nextl, si la fonction n'était pas prédéfinie :

(nextl arg)
; donne :
(prog1
   (car arg)
   (setq arg (cdr arg)))

On affinerait ensuite prog1, etc. ,jusqu'à arriver aux symboles primitifs implantés effectivement par le langage.

On voit donc que le langage permet une « expression de haut niveau » du problème (mapc) sur les éléments primitifs « de bas niveau » (while, next, ...) par des schémas de transformation qui restent transparents à l'utilisateur – c'est l'interprète Lisp qui se charge de réécrire le programme.

Pourquoi présenter cet aspect du langage sous la rubrique « macro-génération » ? c'est que volontairement on se place dans l'optique d'une exécution efficace des programmes : dans l'absolu, parce qu'il est toujours désagréable d'attendre inutilement ; pour les domaines spécifiques où l'efficacité est un impératif crucial – le Temps Réel. Si l'on se plaçait dans une autre optique, on pourrait se limiter à toujours programmer en Lisp, dont la puissance d'expression est suffisante pour couvrir la totalité des techniques de programmation offertes dans les langages – H. Abelson et G. Sussman donnent dans [AbS 83] un panorama complet de la programmation par le biais du lanage Scheme, un dialecte de Lisp.

2.2. l'expression dans un langage de haut niveau

Un langage de « haut niveau », comme Ada, est assez rebelle à l'expression de l'affinage d'un algorithme dans les termes du langage.

Pour représenter la fonction mapv, on pourrait chercher à mettre encore en pratique la généricité d'Ada, mais ceci semble mal adapté ; il faudrait :

• paramétrer la procédure générique mapv par le type d'objet (PHYL, OPER, DRAP) assorti de "faux sous-programmes" en paramètre et par le paramètre fonctionnel fct, lequel aurait a priori un nombre quelconque d'arguments ;
• à chaque utilisation de mapv instancier tous les paramètres (les "vrais" et les "faux").

Plus simplement on recopie le code et de ce fait on disperse la connaissance.

Dans l'exemple, la relative simplicité de la fonction Lisp permet de facilement identifier les étapes de dérivation du programme Lisp dans le texte du programme Ada :

schéma d'identification des programmes Lisp et Ada

En inversant le rôle des partenaires – Lisp et Ada – on perd en automatisation du processus de traduction mais on gagne en faisabilité. Le programme est écrit en Ada, les occurrences d'apparition de la fonction mapv sont les occurrences d'utilisation su « texte » mapv : par affinage, via les « textes », du programme Ada, on reconstruit formellement la fonction Lisp, mais en travaillant dans le langage « exigeant » – « exigeant », si l'on admet que Lisp est plutôt un langage « accomodant ».