Différences

Ci-dessous, les différences entre deux révisions de la page.

--- common_lisp [Le 13/01/2023, 10:35]
dzecniv [Première utilisation]
+++ common_lisp [Le 11/01/2024, 11:56] (Version actuelle)
90.65.241.102 [Développement interactif basé sur une image]
@@ 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.
-<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'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 ====
@@ Ligne 120: / Ligne 122: @@
 ===== 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 =====
@@ Ligne 128: / 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:
-   * 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 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.