Discussion :

[SpiceGuid]

Il y a une chose que je ne comprends pas bien dans la communauté Lisp/Scheme.

D'un côté, et c'est sans doute un des traits les plus excitants de ces langages, on nous dit que Lisp/Scheme n'est pas qu'un langage, grâce au cumul des macros et du code homoiconic c'est un véritable assembleur de langages.
D'ailleurs on a de brillants universitaires qui travaillent à renforcer encore cet aspect.

De l'autre côté, puisque c'est plus "facile" à implémenter, on devrait s'attendre à une réactivité beaucoup plus grande, les interpréteurs devraient rivaliser d'innovation et chercher à implémenter les derniers mécanismes/extensions proposés.

Hé bien ça n'est pas ce que j'observe, les interpréteurs disponibles se répartissent principalement en deux catégories:

• les Lisp/Scheme "compatibles" qui reprennent une(la?) norme en y ajoutant quelques indispensables extensions, lesquelles n'ont malheureusement rien à voir avec les publications évoquées précédemment
• les "nouveaux" langages de script, qui hésitent entre Lisp et Smalltalk/Ruby/JavaScript/Que-sais-je, et dont l'auteur est tellement proche de ses utilisateurs qu'il est dispensé de lire Queinnec

Pourquoi a-t-on si peu d'interpréteurs Lisp/Scheme d'inspiration universitaire ? Pourquoi le retard des interpréteurs est-il plus grand que dans le camp ML ?

[Garulfo]

J'avoue que je ne suis pas sûr de saisir l'essence de ton message.
Personnellement, Lisp (et le dialecte Scheme plus particulièrement) est l'occasion de tester des principes, des approches, de m'implémenter une surcouche pour voir comment je pourrais le faire fonctionner (actuellement c'est les aspects). Maintenant je n'en ferais pas, moi-même, un interpréteur... Je vois donc Lisp comme un moyen de tester et d'expérimenter. En général je passe à autre chose après (à moins que ce ne soit un petit projet).

Mais c'est vrai que je n'ai pas d'intérêt « pratique » dans la création des langages ou dans l'écriture des features avancées. En fait, si j'en ai, mais je n'ai pas le temps car je consacre mes efforts sur mes recherches en GL (publish or die).

Il y a des essais cependant comme en témoigne les langages optionnels dans PLT/Scheme : le real-time par exemple. Beaucoup d'efforts sont concentrés vers les compilateurs plutôt de toute façon. Au final, Chicken, Gambit, Bigloo, Stalin, Guile, ScSh (pour Scheme seulement) me semble être des exemples qui surgissent de l'effervescence chaotique et innovatrice. Tout n'arrive pas à finalité — heureusement quand même — mais il me semble qu'il existe quand même une « bonne réactivité » même si je ne suis pas sûr de ce que ça veut dire ^_^

http://community.schemewiki.org/?sch...mplementations
donne une liste des implémentations de Scheme (et donc pas des Lisp de façon général)... ça me paraît plutôt grand... Il y a des liens vers les bibliothèques aussi... mais tu dois connaître non ? Tu n'as probablement pas posté sans avoir cherché.

Donc peut être que je n'ai pas compris ce que tu voulais dire. Qu'aimerais-tu voir ? C'est peut-être le « d'inspiration universitaire » que je ne comprends pas.

[GnuVince]

Va voir Clojure, un dialecte de Lisp codé en Java. Très intéressant:

• Structures de données immutables
• Support pour la concurrence
• Interopération avec Java et ses librairies
• Structures de données persistantes
• Protocole pour les types séquences

C'est très intéressant, probablement le Lisp avec le plus d'innovation pour le moment et, si Dieu le veut, une bonne chance de faire bonne impression en entreprise.

[SpiceGuid]

@Garulfo
Effectivement, ce lien ne m'est pas inconnu.

@GnuVince
Clojure, Groovy, Jaja et autres ciblent la JVM avec ses atouts et ses défauts (on aime ou on aime pas).
C'est sans doute une 3ième catégories d'interpréteurs qui peuplent la liste ci-dessus: Scheme adapté à une plateforme de langages managés.

Les langages dont je parle sont ceux qui sont ne sont pas représentés dans la liste de http://schemers.org/, quelques exemples qui me viennent à l'esprit :

• ObjVlisp (Pierre Cointe)
• Symmetric Lisp (http://citeseer.ist.psu.edu/245833.html)
• Rascal (http://citeseer.ist.psu.edu/jagannathan94metalevel.html)
• Moostrap (http://citeseer.ist.psu.edu/mulet93definition.html)
• Qi (http://www.lambdassociates.org/)

Et pour cause: si on en rencontre une implémentation c'est toujours une sur-couche de Scheme, jamais un interpréteur indépendant

Sur schemers.org on ne retrouve que partiellement les fonctionnalités avancées, par exemple Galapagos offre les environnements de 1ière classe, mais sans les primitives export et import de la littérature.

[Garulfo]

Les langages dont je parle sont ceux qui sont ne sont pas représentés dans la liste de http://schemers.org/, quelques exemples qui me viennent à l'esprit :

• ObjVlisp (Pierre Cointe)
• Symmetric Lisp (http://citeseer.ist.psu.edu/245833.html)
• Rascal (http://citeseer.ist.psu.edu/jagannathan94metalevel.html)
• Moostrap (http://citeseer.ist.psu.edu/mulet93definition.html)
• Qi (http://www.lambdassociates.org/)

Et pour cause: si on en rencontre une implémentation c'est toujours une sur-couche de Scheme, jamais un interpréteur indépendant

Sur schemers.org on ne retrouve que partiellement les fonctionnalités avancées, par exemple Galapagos offre les environnements de 1ière classe, mais sans les primitives export et import de la littérature.

C'est clair que si tu cherches sur Schemer, tu ne trouveras pas d'implémentation d'autre chose que Scheme ^_^ ObjVLisp par exemple est du Lisp pas du Scheme. Ça ressemble, mais c'est pas la même chose. Tu ne trouveras pas non plus CLisp sur cette liste.

- ObjVLisp est implémenté mais est une extension à VLisp... en fait tout est une « extension » du lisp originel d'une certaine forme.
- Moostrap que tu cites est une extension de Scheme aussi, c'est vrai.
- Qi est disponible sur leur cite. C'est nouvelle implémentation je crois celui-ci. Pas une extension non ?

Mais encore une fois, je ne comprends pas ce qui te dérange dans le fait de faire une surcouche ou de voir une extension. Quand tu as un interpréteur/compilateur bien fait, pourquoi vouloir le refaire ? Il est mieux de faire une extension non ?

En fait, c'est le principe même de la philosophie Lisp : un noyau sur le lambda-calcul et le reste est créé à partir de là. C'est la philosophie qui donne aussi OCaml à la base.

Tous les travaux d'extension ou presque sont universitaires...

Donc... qu'est-ce qui te dérange au fait ?
Si c'est que le langage « officiel » n'implémente pas tout ce qui sort, c'est heureux. Ça serait en général un calvaire si chaque nouvelle version possédait une armée de nouveauté. Car en général ça rend le langage impraticable. C'est pourquoi c'est des extensions que tu peux choisir d'utiliser ou non. De plus quand quelque chose sort dans un article, ce n'est peut-être pas vraiment utile, ou pas vraiment efficace, ou pas vraiment cohérent...
Si jamais GNU C++ implémentait toutes les nouveautés et extensions sur le C++ qui sortent ça serait un compilateur poubelle vite fait. Il faut faire un tri et offrir éventuellement des modules et des extensions.

T'ai-je demandé ce que tu n'aimais pas finalement ??

[SpiceGuid]

J'avais cru comprendre que Qi est une surcouche de Lisp :

Qi runs on CLisp , CMU Lisp, SBCL (May 2007) and Allegro Common Lisp (June 2007).

Oui, avec Lisp/Scheme le sucre syntaxique est bien plus explicite qu'avec un ML et du coup on peut se configurer son langage à la carte plutôt que de l'avoir codé en 'dur'

je viens de comprendre que ça n'est pas du bloatware et que pour soulager mon embarras il suffisait de ne pas lire les sources que je ne comprends pas, et ça passe beaucoup mieux, question d'habitude

[Garulfo]

J'avais cru comprendre que Qi est une surcouche de Lisp :

Ahh bin t'as l'air d'avoir raison. Je pense que j'ai été trompé par

What is Qi?
A language implemented in Common Lisp that generates efficient type secure Lisp programs which you can run on any machine.

Je pensais que ça voulait dire que c'était une implémentation complète et non une surcouche... mais c'est vrai que ton passage semble dire autre chose.