Common Lisp est un langage multi-paradigme, pas purement fonctionnel donc, compilé et fortement typé
Oui, ils ne sont pas purement fonctionnels (OCaml non plus, ni même vraiment Haskell). Par contre même si le typage est fort, ils sont, de base, typés très dynamiquement (il est possible d'écrire des expressions, autres que des casts, qui vont produire une erreur de typage à l'exécution, ou changer impérativement le type d'une variable, par exemple). La notion de typage fort n'est d'ailleurs pas bien définie, j'imagine qu'ici ce que tu veux dire c'est l'absence de conversions implicites et autres caractéristiques de typage laxistes (qu'on peut retrouver dans C qui lui est statiquement typé, mais faiblement), ou peut-être la possibilité d'écrire certaines déclarations optionnelles de types (mais qui, en général, ne sont pas toujours validées statiquement).
Il existe aussi typed-racket.
C'est pour cela que j'avais précisé « par défaut », car, effectivement, à l'aide des macros on peut construire, a posteriori, du typage statique (comme pour typed-racket). Mais je suis content que tu le mentionnes, car construire un système de typage avec des macros, c'est quand même une chose impressionnante et qui mérite d'être connue !
Car Common Lisp permet de déclarer ses types un peu partout, quand on veut. On peut vraiment partir à la chasse à l'optimisation.
Oui, sauf que pour le coup, même si SBCL fait un peu d'inférence, elle n'est pas complète ni garantie, ce qui veut dire qu'il faut choisir un degré de safety pour les déclarations (safety 0) si on veut optimiser agressivement : on risque alors de ne pas être type safe. À utiliser avec modération :-)
Je suppose que tu voulais dire "un peu plus impératif" !
Oups, oui, bien sûr !
Concernant Quicklisp et les bibliothèques, je suis allé un peu vite et mon impression est peut-être faussée, ça fait longtemps que j'ai pas plongé dedans.
[^] # Re: Common Lisp: corrections
Posté par anaseto . En réponse au journal Retour d'expérience sur les langages de programmation. Évalué à 3.
Oui, ils ne sont pas purement fonctionnels (OCaml non plus, ni même vraiment Haskell). Par contre même si le typage est fort, ils sont, de base, typés très dynamiquement (il est possible d'écrire des expressions, autres que des casts, qui vont produire une erreur de typage à l'exécution, ou changer impérativement le type d'une variable, par exemple). La notion de typage fort n'est d'ailleurs pas bien définie, j'imagine qu'ici ce que tu veux dire c'est l'absence de conversions implicites et autres caractéristiques de typage laxistes (qu'on peut retrouver dans C qui lui est statiquement typé, mais faiblement), ou peut-être la possibilité d'écrire certaines déclarations optionnelles de types (mais qui, en général, ne sont pas toujours validées statiquement).
C'est pour cela que j'avais précisé « par défaut », car, effectivement, à l'aide des macros on peut construire, a posteriori, du typage statique (comme pour typed-racket). Mais je suis content que tu le mentionnes, car construire un système de typage avec des macros, c'est quand même une chose impressionnante et qui mérite d'être connue !
Oui, sauf que pour le coup, même si SBCL fait un peu d'inférence, elle n'est pas complète ni garantie, ce qui veut dire qu'il faut choisir un degré de safety pour les déclarations (safety 0) si on veut optimiser agressivement : on risque alors de ne pas être type safe. À utiliser avec modération :-)
Oups, oui, bien sûr !
Concernant Quicklisp et les bibliothèques, je suis allé un peu vite et mon impression est peut-être faussée, ça fait longtemps que j'ai pas plongé dedans.