On compare ici les quatre langages « de la famille Lisp » présentés précédemment. On va voir comment chacun satisfait aux « critères de qualités d'un langage informatique » tels qu'ils sont énumérés dans [Mey 80]. On ne s'attachera pas ici à la syntaxe des langages, qui est dans tous les cas une syntaxe Lisp, c'est-à-dire une syntaxe dont la simplicité a été poussée à l'extrême, sinon à l'excès. On regardera donc plutôt la sémantique donnée à l'évaluation des expressions Lisp de ces langages.
homogénéité, régularité | Scheme Une lambda-expression évaluée n'est pas un objet du langage (un appel à la fonction eval sur un tel objet échoue). | LeLisp Les lambda-expressions ne sont pas des objets de première classe, et ne peuvent donc être manipulées de la même manière que les variables. | Symmetric Lisp Pour les lambda-expressions, cf. LeLisp. | « Moi aussi » Oui, du fait de la simplicité des concepts. |
orthogonalité | Scheme L'évaluation parallèle des « environnements » : l'évaluation est parallèle pour des définitions de lambda-expressions, mais non pour les variables. | LeLisp Le terme de tête des expressions n'est pas évalué, ce qui nécessite l'emploi explicite de la fonction apply quand on utilise un paramètre fonctionnel. | Symmetric Lisp L'évaluation parallèle des « environnements » : - pour les symboles, un symbole indéfini est virtuellement quoté, - pour les lambda-expressions évaluées avec un nombre partiel d'arguments, l'évaluation répond mal au schéma général. | « Moi aussi » L'évaluation parallèle des « environnements » : l'ordre des déclarations importe. Deux environnements qui ne diffèrent que par l'ordre des déclarations qu'ils comportent pourront être évalués différemment. |
simplicité | Scheme Oui, si l'on ne fait pas de calcul symbolique (la fonction eval, qui évalue une expression symbolique, nécessite en paramètre un environnement, ce qui rend son emploi malaisé). | LeLisp Oui, "par omission" des situations complexes (dont : une lambda-expression est évaluée identiquement à elle-même). | Symmetric Lisp Beaucoup de concepts, beaucoup de cas dont la sémantique n'est pas précisée (par ex : acar sur un argument qui n'est pas de type alpha). | « Moi aussi » Oui. Ce qui pourrait se révéler être une complication : on peut quasiment tout faire, donc le respect d'une discipline s'impose. |
généralité | Scheme Oui, dans le "créneau" de la programmation structurée : - portée locale des déclarations, - possibilité de définir des « modules » (les environnements) = des fonctions + des données. | LeLisp Oui, dans le "créneau Lisp" : - calcul symbolique, - manipulation de listes. | Symmetric Lisp Oui, cf. LeLisp. | « Moi aussi » Non, on s'intéresse spécifiquement à la manipulation de caractères. |
extensibilité | Scheme Oui, les lambda-expressions sont des objets de première classe, on les utilise donc de la même façon que les fonctions prédéfinies. Scheme Non, pas de variable libre, la fonction eval demande en argument un environnement. | LeLisp Oui, avec : - les macros Lisp, - la possibilité de définir des variables libres, - la fonction eval. | Symmetric Lisp Oui, cf. LeLisp. Egalement, la manipulation des environnements. | « Moi aussi » Oui, avec : - la liaison dynamique, - la possibilité de référence à un environnement. |
compilabilité, "exécutabilité" | Scheme Exécutable, et surtout compilable. C'est un des arguments avancés pour le choix de la « liaison statique » | LeLisp Exécutable, "par omission". Difficilement compilable (en particulier, le compilateur refuse la définition dynamique de fonctions "flet", qu'il ne peut reconnaître comme des lambda-expressions). | Symmetric Lisp Exécutable, mais certains comportements restent indéfinis (en particulier : cas de cycles dans l'évaluation parallèle d'un environnement). Difficilement compilable. Problème des environnements ouverts ( "open-alpha") : comment gérer l'espace mémoire. | « Moi aussi » Exécutable, et sûrement pas compilable (mais certainement "optimisable", en particulier lors de la reconstruction dynamique de l'environnement lexical de définition). |
clarté | Scheme Oui, du fait de la fermeture lexicale (« liaison statique ») : dans une vision descendante du programme, on a la garantie du lien lexical entre définition et utilisation d'un symbole. | LeLisp Oui, si on excepte les « effets de bord imprévisibles », qui sont le fait de la « liaison dynamique » des symboles. | Symmetric Lisp Oui, mais cf. LeLisp. De plus, la gestion dynamique des environnements accroît le nombre de ces cas « imprévisibles ». | « Moi aussi » Oui, mais cf. Symmetric Lisp, à l'intérieur d'une définition. A l'extérieur, la gestion de l'« environnement local » garantit la construction dynamique de l'environnement lexical de définition. |
sécurité, fiabilité | Scheme Oui, dans une vision descendante du programme : les liens sont statiquement identifiés. | LeLisp Oui, exceptées les difficultés inhérentes à la « liaison dynamique » (les « effets de bord »). Le bon emploi des variables libres est laissé à la discrétion de l'utilisateur. | Symmetric Lisp Oui, si l'on suppose une méthodologie d'emploi associé. L'utilisateur gérant dynamiquement les environnements, peu de contrôles statiques sont possibles. | « Moi aussi » Oui, mais cf. Symmetric Lisp ; une première "méthodologie" est l'emploi des « environnements locaux ». |
souplesse, comodité d'emploi | Scheme Oui, pour la définition de « modules » (des fonctions + des données). Scheme Non, pour le calcul symbolique, du fait de la contrainte de la « liaison statique ». | LeLisp Il est difficile d'attacher à un symbole à valeur fonctionnelle un environnement de définition. Les données à valeur persistante sont explicitement déclarées ( "closure"). | Symmetric Lisp Oui, si l'on gère bien les environnements. | « Moi aussi » Oui, mais cf. Symmetric Lisp. La nécessité d'indiquer les « environnements locaux » peut être contraignante (beaucoup d'empilement d'environnements pour nommer un concept). |
puissance expressive | Scheme Oui, une lambda-expression représente un « module ». Scheme Non, pour le calcul symbolique (et en particulier, pas de variable libre). | LeLisp Oui, excepté le problème de fermeture lexicale, difficile à mettre en œuvre. Inversement la « liaison dynamique » favorise l'utilisation de variables libres, qui autorisent la définition d'« abstractions de haut niveau ». | Symmetric Lisp Oui, mais cf. LeLisp : demande une bonne gestion des environnements par l'utilisateur. Oui, avec les environnements ouverts ( "open-alpha") pour la manipulation de flots de données infinis. | « Moi aussi » Oui, mais cf. Symmetric Lisp, à l'intérieur d'une définition. A l'extérieur, on reconstruit dynamiquement l'environnement lexical, et l'utilisateur peut (volontairement) fausser cette reconstruction – surcharge de définition. |
complétude de la définition | Scheme Oui, les cas d'erreur sont identifiés. Ce sont : l'évaluation parallèle de définitions de variables mutuellement définies ; l'évaluation d'une lambda-expression évaluée. | LeLisp Oui, "par omission". | Symmetric Lisp Oui, si l'on suppose que les formules non valides retournent une valeur conventionnelle. | « Moi aussi » Oui, du fait du peu de concepts introduits. |