Je pense que c’est une des solutions les plus matures pour le moment.
Common Lisp c’est un standard pour lequel il existe plusieurs compilateurs (SBCL, ECL, Clasp, Parenscript, etc).
Le langage se veut à la fois permettre des abstractions « haut-niveau », mais permet également de mettre les mains dans le cambouis quand c’est nécessaire. Il propose notamment un système d’objet (par prototypes) CLOS (Common Lisp Object System), une gestion d’erreurs très avancée, et l’écosystème est remarquablement mature.
Scheme c’est également un standard (ou plutôt un ensemble de standards à différentes versions : on doit en être à R7RS) pour lequel il existe aussi plusieurs compilateurs (Chez, Chibi, Chicken, MIT Scheme, Guile, etc).
Le langage se veut minimaliste, contrairement à CL. Les standards permettent un peu moins à mon goût de mettre les mains dans le cambouis, mais l’approche fonctionnelle est souvent plus mise en avant. Il ne propose pas de système d’objet par défaut (mais plusieurs bibliothèques existent pour faire ça), mais il propose un système de macros hygiéniques (qui ne brisent pas la frontière entre le code à la compilation et le code à l’exécution), et les SRFI (Scheme Request For Implementation) qui permettent d’étendre amplement ce que l’on peut faire avec le langage.
Je trouve par ailleurs qu’il est plus simple d’utiliser différentes implémentation sur les mêmes sources en Scheme qu’en Common Lisp.
Je dirai qu’une des principales différences entre un Scheme et un Common Lisp, c’est la séparation des espaces de noms entre les fonctions et les variables.
En scheme, il n’y a pas de différence entre define une fonction ou une variable :
funcall nous permet de considérer le contenu d’une variable comme une référence vers une fonction (ou une lambda), et de l’appeler en tant que tel. On n’a pas du tout besoin de cette notion avec un Scheme.
[^] # Re: et parenscript ?
Posté par Leirda . En réponse au journal LIPS : Lisp dans le navigateur. Évalué à 3.
Je pense que c’est une des solutions les plus matures pour le moment.
Common Lisp c’est un standard pour lequel il existe plusieurs compilateurs (SBCL, ECL, Clasp, Parenscript, etc).
Le langage se veut à la fois permettre des abstractions « haut-niveau », mais permet également de mettre les mains dans le cambouis quand c’est nécessaire. Il propose notamment un système d’objet (par prototypes) CLOS (Common Lisp Object System), une gestion d’erreurs très avancée, et l’écosystème est remarquablement mature.
Scheme c’est également un standard (ou plutôt un ensemble de standards à différentes versions : on doit en être à R7RS) pour lequel il existe aussi plusieurs compilateurs (Chez, Chibi, Chicken, MIT Scheme, Guile, etc).
Le langage se veut minimaliste, contrairement à CL. Les standards permettent un peu moins à mon goût de mettre les mains dans le cambouis, mais l’approche fonctionnelle est souvent plus mise en avant. Il ne propose pas de système d’objet par défaut (mais plusieurs bibliothèques existent pour faire ça), mais il propose un système de macros hygiéniques (qui ne brisent pas la frontière entre le code à la compilation et le code à l’exécution), et les SRFI (Scheme Request For Implementation) qui permettent d’étendre amplement ce que l’on peut faire avec le langage.
Je trouve par ailleurs qu’il est plus simple d’utiliser différentes implémentation sur les mêmes sources en Scheme qu’en Common Lisp.
Je dirai qu’une des principales différences entre un Scheme et un Common Lisp, c’est la séparation des espaces de noms entre les fonctions et les variables.
En scheme, il n’y a pas de différence entre
defineune fonction ou une variable :est rigoureusement équivalent à :
Common Lisp, quant à lui, utilise bien deux mots-clés distincts :
n’est pas du tout pareil à :
funcallnous permet de considérer le contenu d’une variable comme une référence vers une fonction (ou une lambda), et de l’appeler en tant que tel. On n’a pas du tout besoin de cette notion avec un Scheme.