Discussion :

[Pyramidev]

Bonjour,

Depuis un certain temps, par curiosité intellectuelle, je recherche, parmi les langages qui offrent (ou peuvent offrir) facilement les performances du C, lesquels poussent le plus loin l'abstraction. Idéalement, il faudrait aussi de bons contrôles pendant la compilation.
À propos des performances, pour être plus précis, cette recherche n'exclut pas les langages dont les écarts actuels de performances par rapport au C ne viennent que d'un manque de maturité des compilateurs par rapport à ceux du C.

En C++, les macros du préprocesseur et les templates permettent de faire de l'abstraction sans coût, mais ont des limites.

En langage D, les templates sont meilleurs qu'en C++ et on a plein de fonctionnalités assez balèzes pour faire de l'abstraction sans coût, comme le mot-clef mixin, le static foreach et d'autres fonctionnalités intéressantes, mais cela reste en dessous des macros du Lisp.

Finalement, hier, j'ai pris conscience qu'il était possible de créer un dialecte du Lisp statiquement typé sans ramasse-miettes obligatoire, ce qui permettrait de pousser plus loin l'abstraction offerte par le langage D, tout en ayant la possibilité de conserver les performances du C. En fait, ce n'est pas un problème d'avoir du typage dynamique et d'utiliser le ramasse-miettes pendant la phase d'expansion des macros. Par contre, quand toutes les macros ont été déroulées, il faut que le code généré puisse être entièrement statiquement typé et ne soit pas obligé d'utiliser le ramasse-miettes. Alors, le compilateur peut à la fois faire plein de contrôles et optimiser le plus possible.

Alors, j'ai cherché sur internet et je suis tombé sur une page qui a mentionné plusieurs langages, dont Dale et Carp.

Avant que je ne continue mes recherches, je souhaiterais connaître la réponse à la question suivante :
Parmi les dialectes du Lisp statiquement typés sans ramasse-miettes obligatoire, lesquels sont les moins inconnus ?

Contexte : actuellement, dans ma todo list, du côté des dialectes du Lisp, j'ai prévu de continuer d'étudier le Common Lisp, puis j'étudierai Scheme, puis Racket et Typed Racket. Ensuite, je regarderai peut-être Clojure et Typed Clojure. Après, je me pencherai sur les Lisp statiquement typés sans ramasse-miettes obligatoire, mais je ne sais pas encore par où commencer.

[byjav]

Moi, je connais par nom typed racket et newLisp et je ne connais pas les autres.

[Pyramidev]

Typed Racket possède un typage statique, mais il me semble que la mémoire est gérée par un ramasse-miettes.
Concernant newLisp, je ne sais pas exactement comment est gérée la mémoire, mais je crois qu'il n'y a pas de typage statique.

[byjav]

Je me souviens aussi de ce projet (mort, évidemment)
https://www.cliki.net/c-amplify
Il s’agit d’écrire C en S-expressions.

[jack-ft]

Bonojur.
Pourrais-tu préciser quel est ton problème avec le ramasse-miettes?

Juste pour information, de mon temps, il existait environ 2 types de gc: le "stop & copy" et l'incrémental.

Il y a quelques lustres, j'avais écrit un séquenceur MIDI en le_lisp (le lisp français de l'INRIA/ILOG), dont le gc était en stop & copy.
Comme le séquenceur devait pouvoir jouer de la musique en temps réel en concert, l'appel du gc était très gênant car la musique s'arrêtait complètement pendant environ 2 secondes, ce que n'appréciaient pas les compositeurs...

Du coup, j'avais développé des outils de "chasse aux cons" (NDA: pour éviter toute ambiguïté, il faut prononcer "chasse aux conses" ), c'est-à-dire "réglementer" les usages d'allocation dynamique de mémoire, comme on le faisait normalement en C à l'époque.

Les fonctions comme "cons" "list" "append" "mapcar" etc. font l'équivalent d'un appel à "malloc" en C et j'ai donc dû faire un usage intensif de la fonction "free" qui remet la liste passée en paramètre dans la liste des "cons" disponibles, avec la précaution de ne pas stocker ces "cons" dans la mémoire normale sous peine de tout casser!
J'ai privilégié les "rplaca" et "rplacd" pour réutiliser des "cons" déjà alloués.
J'ai même dû bidouiller une fonction en assembleur LLM3 car la version fournie créait un vecteur à chaque appel et qu'il n'y avait pas de "free" pour les vecteurs.

Nous avons testé notre séquenceur pendant plusieurs heures sans aucun appel de "gc", mais avec une grande satisfaction!

Tout ça pour dire qu'on peut utiliser un langage avec gc intégré, mais sans jamais l'utiliser!

Évidemment, il y a un coût en développement et en sécurité... exactement comme en C !

[Pyramidev]

Bonjour,

Pourrais-tu préciser quel est ton problème avec le ramasse-miettes?

Je recherche un langage dans lequel je peux gérer à la fois le bas niveau (à l'échelle du C) et architecturer le code en respectant le DRY (Don't Repeat Yourself), sans que le langage ne me mette des bâtons dans les roues, ni pour le bas niveau, ni pour le DRY.

Or, les langages qui ont un ramasse-miettes obligatoire me mettent les bâtons dans les roues quand je veux gérer le bas niveau.

Actuellement, je suis habitué à développer en C++ dans lequel je peux gérer la mémoire. Par exemple, je peux stocker un objet dans la pile pour éviter une allocation dynamique. Je peux aussi stocker un objet à l'intérieur d'un autre objet. Quand je veux stocker des objets de même type dans la mémoire dynamique, je peux allouer la mémoire pour plusieurs de ces objets d'un coup. Je peux aussi positionner des objets de même type les uns à la suite des autres en mémoire, ce qui permettra au compilateur de vectoriser certaines opérations quand ces objets seront traités séquentiellement. D'ailleurs, en C++, en général, on n'utilise pas de listes chaînées.

D'ailleurs, pour gérer le bas niveau, Rust me semble encore meilleur que le C++, entre autres grâce à ses nombreux contrôles à la compilation. Mais trouver un Lisp statiquement typé, sans ramasse-miettes obligatoire et qui bénéficie en plus des contrôles du Rust me semble utopique.

[Pyramidev]

Je me souviens aussi de ce projet (mort, évidemment)
https://www.cliki.net/c-amplify
Il s’agit d’écrire C en S-expressions.

En effet, pour le projet c-amplify, le dernier commit date du 9 mars 2010.

Du côté des petits projets pour écrire du C en S-expressions, je suis tombé sur deux projets plus récents :

• LISP/c, dont le dernier commit date du 18 mai 2016 et
• sxc, dont le dernier commit date du 22 juin 2018.

Concernant LISP/c, le dernier commit consistait à modifier le README.md, notamment pour y ajouter « Version 2.0 is coming out very soon. » Mais, plusieurs années, ça fait beaucoup pour « very soon. »

D'ailleurs, pour gérer le bas niveau, Rust me semble encore meilleur que le C++, entre autres grâce à ses nombreux contrôles à la compilation. Mais trouver un Lisp statiquement typé, sans ramasse-miettes obligatoire et qui bénéficie en plus des contrôles du Rust me semble utopique.

Je réponds à mon propre message.

Concernant le langage Carp, si j'en crois le fichier Memory.md, Carp possède un borrow checker (un concept qui vient du Rust pour la gestion de la mémoire), ce qui m'a agréablement surpris.

Je suis allé faire un tour sur le site de Erik Svedäng, le concepteur du langage Carp. Dans la page consacrée à Carp, j'ai lu :
« Born out of frustration with current tools for digital game making — and a love for the Lisp family of languages — I invented Carp. It’s a programming language designed with game making in mind, focused on speed and predictable performance. »

C'est cohérent avec le peu que j'ai vu du langage.

C'est bon signe. Carp est peut-être le langage que je cherchais. Mais je vérifierai ça une autre fois. J'ai d'autres choses à étudier avant.