Différences
Ci-dessous, les différences entre deux révisions de la page.
| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
|
common_lisp [Le 18/11/2022, 14:05] dzecniv [Liens externes] |
common_lisp [Le 11/01/2024, 11:56] (Version actuelle) 90.65.241.102 [Développement interactif basé sur une image] |
||
|---|---|---|---|
| Ligne 11: | Ligne 11: | ||
| Les premières origines des langages Lisp remontent aux années 60 suivant les travaux de John McCarthy. | Les premières origines des langages Lisp remontent aux années 60 suivant les travaux de John McCarthy. | ||
| - | On distinguera plusieurs dialectes de la famille des Lisp: Common Lisp, la famille des Scheme, Clojure, et les langages avec une syntaxe Lisp qui transpilent dans un autre langage hôte (tel que LFE: Lisp-Flavored Erlang). | + | On distinguera plusieurs dialectes de la famille des Lisp: Common Lisp, la famille des Scheme, Clojure, les langages spécialisés (Emacs Lisp, AutoCAD) et les langages avec une syntaxe Lisp qui transpilent dans un autre langage hôte (tels que LFE pour "Lisp-Flavored Erlang" ou Fennel sur la plateforme Lua). |
| ===== Programmer en Common Lisp ===== | ===== Programmer en Common Lisp ===== | ||
| Ligne 66: | Ligne 66: | ||
| Et, enfin: la structure des expressions en Lisp est la même que la structure utilisée pour représenter des listes: les parenthèses. ''(list 40 2)'' est une liste, '''(40 2)'' est la même liste écrite avec un raccourci, et ''(+ 40 2)'' a la même structure qu'une liste. Mais quand on l'évalue, on appelle la fonction ''+'' avec deux opérandes. Ainsi, un programme Lisp est, dans la syntaxe Lisp, simplement une liste de listes imbriquées. | Et, enfin: la structure des expressions en Lisp est la même que la structure utilisée pour représenter des listes: les parenthèses. ''(list 40 2)'' est une liste, '''(40 2)'' est la même liste écrite avec un raccourci, et ''(+ 40 2)'' a la même structure qu'une liste. Mais quand on l'évalue, on appelle la fonction ''+'' avec deux opérandes. Ainsi, un programme Lisp est, dans la syntaxe Lisp, simplement une liste de listes imbriquées. | ||
| + | <note tip>L'option ''%%--remember%%'' de rlwrap permet d'auto-compléter avec la touche TAB les mots précédemment écrits. L'option ''-i'' permet de ne pas faire attention à la casse (majuscule ou minuscule, peu importe), l'option ''-c'' permet d'auto-compléter les fichiers.</note> | ||
| + | |||
| + | <note tip>L'implémentation CLISP, également dans Debian, propose une ligne de commande pour le terminal qui est ergonomique par défaut: la complétion des fonctions existantes est disponible, etc. Pas besoin de ''rlwrap''. Mais attention cette implémentation est vieillissante, n'est pas totalement aux normes du langage, elle produit moins de "warnings" que SBCL, le code qu'elle génère est moins efficient que SBCL. On l'évitera quand une application prend de l'ampleur.</note> | ||
| ==== Avec un fichier texte ==== | ==== Avec un fichier texte ==== | ||
| Ligne 119: | Ligne 122: | ||
| ===== Les éditeurs ===== | ===== Les éditeurs ===== | ||
| - | Pendant longtemps, les seuls *bons* éditeurs disponibles étaient [[emacs|Emacs]] et son plugin Slime ainsi que l'IDE LispWorks, qui vient avec l'implémentation du même nom, mais qui est propriétaire. Aujourd'hui, il existe de bons modules pour des éditeurs populaires. Nous vous référons à: https://lispcookbook.github.io/cl-cookbook/editor-support.html | + | Pendant longtemps, les seuls *bons* éditeurs disponibles étaient [[emacs|Emacs]] et son plugin Slime ainsi que l'IDE LispWorks, qui vient avec l'implémentation du même nom, mais qui est propriétaire. Aujourd'hui, il existe de bons modules pour des éditeurs populaires. Référez-vous à: https://lispcookbook.github.io/cl-cookbook/editor-support.html |
| ===== Développement interactif basé sur une image ===== | ===== Développement interactif basé sur une image ===== | ||
| Ligne 127: | Ligne 130: | ||
| Avec un bon IDE pour CL (typiquement Emacs et Slime, mais aussi SLIMA pour Atom et d'autres), on peut développer son programme interactivement de A à Z, sans avoir besoin de redémarrer le processus Lisp sous-jacent. Toutes les modifications sont ajoutées au fil de l'eau, les tests peuvent être lancés depuis la même image au fil de l'eau. Un cas d'usage classique est: | Avec un bon IDE pour CL (typiquement Emacs et Slime, mais aussi SLIMA pour Atom et d'autres), on peut développer son programme interactivement de A à Z, sans avoir besoin de redémarrer le processus Lisp sous-jacent. Toutes les modifications sont ajoutées au fil de l'eau, les tests peuvent être lancés depuis la même image au fil de l'eau. Un cas d'usage classique est: | ||
| - | * on écrit du code dans fichier, on démarre le plugin Lisp et on connecte un REPL à son éditeur. Lorsqu'on a écrit une fonction, on compile cette fonction avec un raccourci clavier (C-c C-c). On a en effet compilé dans ce cas UNE fonction. Le compilateur Lisp nous donne s'il le faut des messages de warning: incompatibilités de types, une variable n'est pas utilisée… Si la compilation a réussi (j'insiste: la fonction a été compilée, dans le cas de SBCL c'est en code machine efficient. Dans le cas de l'implémentation CLISP ce serait du "bytecode" intermédiaire) on peut utiliser notre fonction depuis le REPL. Cela permet de la tester, ou de continuer à travailler. Souvent, un développeur Lisp garde son éditeur et son REPL ouvert pendant plusieurs jours, puisqu'il y a rarement besoin de le redémarrer. | + | * on écrit du code dans un fichier, on démarre le plugin Lisp et on connecte un REPL à son éditeur. Lorsqu'on a écrit une fonction, on compile cette fonction avec un raccourci clavier (C-c C-c). **On a compilé dans ce cas UNE fonction**. Le compilateur Lisp nous donne s'il le faut des messages de warning: incompatibilités de types, une variable n'est pas utilisée… Si la compilation a réussi (j'insiste: la fonction a été compilée, dans le cas de SBCL c'est en code machine efficient. Dans le cas de l'implémentation CLISP ce serait du "bytecode" intermédiaire) on peut utiliser notre fonction depuis le REPL. Cela permet de la tester, ou de continuer à travailler. Souvent, un développeur Lisp garde son éditeur et son REPL ouvert pendant plusieurs jours, puisqu'il y a rarement besoin de le redémarrer. |
| - | * si notre appel de la fonction dans le REPL échoue, nous obtenons une fenêtre de débogueur interactif. Dans le cas de LispWorks, c'est une fenêtre graphique facile avec des boutons. Dans le cas d'Emacs et Slime, c'est une fenêtre en mode texte, avec un menu pour effectuer des actions. Dans ce débogueur, nous voyons le message d'erreur, la pile des appels de fonction avec leurs arguments. Nous pouvons évaluer du code dans le contexte de cette erreur. Nous pouvons aller à la ligne d'où provient l'erreur, la corriger, compiler le nouveau code (avec le raccourci clavier), retourner dans le débogueur, redémarrer le programme du début ou bien le redémarrer depuis un appel de fonction que l'on choisit. Le programme reprend son exécution de là où on le demande, et on peut observer son exécution finir avec succès. | + | * si notre appel de la fonction dans le REPL échoue, nous obtenons une fenêtre de **débogueur interactif**. Dans le cas de LispWorks, c'est une fenêtre graphique facile avec des boutons. Dans le cas d'Emacs et Slime, c'est une fenêtre en mode texte, avec un menu pour effectuer des actions. Dans ce débogueur, nous voyons le message d'erreur, la pile des appels de fonction avec leurs arguments. Nous pouvons évaluer du code dans le contexte de cette erreur. Nous pouvons aller à la ligne d'où provient l'erreur, la corriger, compiler le nouveau code (avec le raccourci clavier), retourner dans le débogueur, redémarrer le programme du début ou bien le redémarrer depuis un appel de fonction que l'on choisit. Le programme reprend son exécution de là où on le demande, et on peut observer son exécution finir avec succès. |
| <note tip>Common Lisp permet (mais n'impose pas) une différence de travail fondamentale, où l'on agit de manière interactive et incrémentielle avec l'image Lisp: au lieu d'un cycle typique édition / compilation / attente / test, on obtient un cycle édition / test beaucoup plus court. </note> | <note tip>Common Lisp permet (mais n'impose pas) une différence de travail fondamentale, où l'on agit de manière interactive et incrémentielle avec l'image Lisp: au lieu d'un cycle typique édition / compilation / attente / test, on obtient un cycle édition / test beaucoup plus court. </note> | ||
| - | * on peut installer de nouvelles librairies en restant dans le REPL, il n'y a pas besoin de redémarrer l'interpréteur. | + | * on peut **installer de nouvelles librairies en restant dans le REPL**, il n'y a pas besoin de redémarrer l'interpréteur. |
| * si l'on définit une classe (''defclass'') et quelques objets, instances de cette classe, puis que l'on modifie la définition de cette classe, les objets existants restent en mémoire. Mieux, ils sont mis à jour. Par exemple, si l'on crée un nouvel attribut pour cette classe, les objets existants (créés lorsque cet attribut n'était pas encore défini) vont être mis à jour pour obtenir ce nouvel attribut dans sa valeur par défaut. | * si l'on définit une classe (''defclass'') et quelques objets, instances de cette classe, puis que l'on modifie la définition de cette classe, les objets existants restent en mémoire. Mieux, ils sont mis à jour. Par exemple, si l'on crée un nouvel attribut pour cette classe, les objets existants (créés lorsque cet attribut n'était pas encore défini) vont être mis à jour pour obtenir ce nouvel attribut dans sa valeur par défaut. | ||
| * Mieux, le langage possède des mécanismes qui permettent de contrôler si et comment la mise à jour de ces objets existants s'effectue. Cela paraît fou, voire inutile! Mais ce sont des mécanismes nécessaires pour des programmes au long cours. | * Mieux, le langage possède des mécanismes qui permettent de contrôler si et comment la mise à jour de ces objets existants s'effectue. Cela paraît fou, voire inutile! Mais ce sont des mécanismes nécessaires pour des programmes au long cours. | ||
| * on peut mettre à jour un programme "à la volée" sans rien faire de spécial: on utilise la fonction ''load'' vue plus haut, et le nouveau code est intégré dans le programme en cours. Si une fonction est re-définie, et bien les nouveaux appels de cette fonction utiliseront la nouvelle définition. | * on peut mettre à jour un programme "à la volée" sans rien faire de spécial: on utilise la fonction ''load'' vue plus haut, et le nouveau code est intégré dans le programme en cours. Si une fonction est re-définie, et bien les nouveaux appels de cette fonction utiliseront la nouvelle définition. | ||
| + | * on peut se connecter à un programme en cours d'exécution et **évaluer du code depuis l'intérieur de ce programme**. Il est déconseillé de modifier le code de cette façon (toute trace du code devrait être gardée dans des fichiers et gérée avec un gestionnaire de versions, comme d'habitude), mais on peut explorer l'état du programme de cette façon. | ||
| ===== Logiciels liés à Common Lisp ===== | ===== Logiciels liés à Common Lisp ===== | ||
| Ligne 147: | Ligne 151: | ||
| * [[https://sourceforge.net/projects/maxima/files/|Maxima]] (et son [[https://wxmaxima-developers.github.io/wxmaxima/|interface graphique Wxmaxima]]) est un "Computer Algebra System". | * [[https://sourceforge.net/projects/maxima/files/|Maxima]] (et son [[https://wxmaxima-developers.github.io/wxmaxima/|interface graphique Wxmaxima]]) est un "Computer Algebra System". | ||
| * [[https://kandria.com/|Kandria]] est un jeu de plateforme publié sur Steam. | * [[https://kandria.com/|Kandria]] est un jeu de plateforme publié sur Steam. | ||
| + | * [[https://github.com/lem-project/lem/wiki|Lem]] est un éditeur de texte écrit in Common Lisp, qui fonctionne avec un grand choix de langages grâce à son client LSP (Language Server Protocol). Il est prêt à l'emploi pour Common Lisp. | ||
| Pour plus, voir les liens ci-dessous. | Pour plus, voir les liens ci-dessous. | ||