Scheme exécuté dans WebAssembly — le projet Hoot

• Projet conçu pour permettre l’exécution de code Scheme dans WebAssembly (navigateurs prenant en charge GC), avec un compilateur Scheme→Wasm et une toolchain Wasm complète
• Construit sur GNU Guile, sans dépendances supplémentaires, avec une structure autonome (toolchain self-contained)
• Il est possible de tester des binaires Hoot via l’interpréteur Wasm dans l’environnement REPL de Guile
• La version la plus récente est v0.7.0, avec liens vers les fichiers de publication, signatures, documentation et annonce officielle
• Tentative d’étendre le langage Scheme à l’environnement web, montrant le potentiel d’extension de l’écosystème Lisp dans le navigateur

---

Présentation de Hoot

• Hoot est un projet développé par le Spritely Institute pour exécuter du code Scheme sur WebAssembly (Wasm)
  • Fonctionne dans les navigateurs web prenant en charge la fonctionnalité GC (Garbage Collection)
  • Inclut un compilateur transformant le code Scheme en Wasm, ainsi qu’une toolchain complète pour le développement autour de Wasm
• Il est construit sur Guile et ne nécessite aucune dépendance externe supplémentaire
  • La toolchain est entièrement autonome et intègre un interpréteur Wasm, permettant de tester directement des binaires Hoot dans le REPL de Guile

Distribution et développement

• La dernière version publiée est la v0.7.0, avec fichiers de téléchargement, signatures, documentation et lien vers l’annonce officielle
  • Fichier de publication : guile-hoot-0.7.0.tar.gz
  • Les fichiers de documentation et de signature, ainsi qu’une page d’actualités associée, sont également fournis
• La version de développement est accessible dans le dépôt Codeberg (https://codeberg.org/spritely/hoot)

Ressources associées

• Plusieurs articles sont proposés autour de la création de pages web interactives avec Hoot et de l’exécution de Scheme dans le navigateur
  • “Building interactive web pages with Hoot”
  • “Scheme in the browser: A Hoot of a tale”
  • “Lisp Game Jam - ‘Wireworld’ - Hoot's low level Wasm tooling in action”
• Le blog d’Andy Wingo et une vidéo d’entretien de System Crafters permettent aussi d’obtenir des informations supplémentaires du point de vue des développeurs

[GN⁺]

Commentaires Hacker News

• Il est intéressant de voir que le développement de Guile s’accélère ces derniers temps.
  Cela dit, c’est un peu dommage de voir autant d’anciens membres de la communauté Racket s’y déplacer.
  C’est triste quand une communauté se fragmente, et Guile donne encore l’impression d’être en retrait par rapport à Racket en matière de performances et de diversité des bibliothèques.

  • D’après mon expérience, c’était plutôt l’inverse. Guile démarrait plus vite que Racket, et comme ce que je fais est surtout centré sur les E/S, Guile me convenait mieux.
    Les benchmarks racontent autre chose, mais ça vaudrait le coup de vérifier soi-même.
  • Guile repose actuellement sur une architecture VM en bytecode + JIT, donc c’est plus lent que Chez/Racket, mais ça reste assez rapide.
    Suffisamment pour faire tourner des jeux à 60 fps, et le GC se déclenche rarement.
    L’écosystème de bibliothèques s’est aussi beaucoup amélioré par rapport à avant.
  • Je me souviens avoir lu un billet de blog sur un problème de « Missing Stair » dans la communauté Racket.
    (wiki Missing Stair)
    Après cet incident, la fragmentation de la communauté semble avoir été une conséquence difficile à éviter.
  • C’est une bonne chose que Guile attire l’attention, mais il ne faut pas pour autant sous-estimer Racket.
    • Le travail de WASM sur Guile est prometteur, et côté Racket, Jens Axel Soegaard développe aussi un compilateur lié à ce sujet.
    • Le rehosting basé sur Chez de Racket semble être un bon choix, et son architecture interne est probablement devenue plus simple à manipuler que celle de Guile.
    • Racket conserve de gros atouts en métaprogrammation et sur son système de modules.
      Par exemple, on peut écrire des tests avec Overeasy et de la documentation inline avec McFly.
    • Les langages de la famille Scheme restent ceux des gens qui n’ont pas besoin de penser en termes de « mots-clés employables ».
      L’ambiance dans le secteur est aussi devenue plus difficile récemment, entre la génération de code par IA et l’effondrement des investissements VC.
  • Je me demande si Hoot, une autre implémentation de Guile (par exemple fonctionnant au-dessus de V8), a déjà fait l’objet de benchmarks.

• Le projet en lui-même est superbe, mais j’aimerais qu’il utilise un autre langage que Guile.

  • Cela dit, Guile est le langage de Guix, donc son écosystème est riche.
    Avec Guix, on peut créer facilement des builds reproductibles.
    Il reste toutefois des problèmes autour du débogueur, de l’expanseur de macros et de la bibliothèque standard R6RS.
    Le support multicœur de Racket était autrefois lourd, mais il semble s’être amélioré aujourd’hui par rapport aux fibers/futures de Guile.
  • Si l’idée est d’utiliser une autre implémentation de Scheme que Guile, alors en écrivant en syntaxe standard R6RS/R7RS, la portabilité ne devrait pas être difficile.

• Content de revoir ce genre d’initiative de compilation vers WASM.
  À une époque, j’avais l’impression que l’enthousiasme était retombé, mais si davantage de langages de ce type apparaissent, tant mieux, car cela permet d’éviter JavaScript.

• Ce projet m’a fait réfléchir à la future orientation des langages de programmation.
  Si l’IA devient l’auteur principal du code, les langages évolueront sans doute davantage vers la clarté et la réduction des erreurs.
  Ce sera moins amusant pour les humains, mais plus facile à corriger.
  Dans ce contexte, des langages comme Rust devraient probablement rester en haut du classement.
  Je me demande toutefois si un langage comme Hoot peut trouver sa place dans des domaines spécialisés, ou s’il restera un langage de loisir.

  • Je me suis posé la même question sur ce à quoi ressemblerait un langage centré sur l’IA, et je pense que la famille Scheme/Lisp est probablement plus proche de cette direction.

• Vraiment génial ! Je me demande si ça pourrait aussi fonctionner sur Cloudflare Workers.

• J’aimerais que Guile offre un meilleur support de Windows.

• repl.wasm fait 1,6 MiB, ce qui semble un peu gros. Je me demande quelle taille fait l’exemple todo.

  • Ce REPL n’est pas le plus petit binaire, mais il descend à 339 K une fois compressé avec gzip.
    L’optimisation wasm-opt n’a pas encore été appliquée.
    Hoot est un compilateur AOT, donc le REPL embarque du code supplémentaire, comme l’expanseur de macros, le système de modules du runtime, l’interpréteur, etc.
    L’exemple réel todo.wasm fait environ 566 K (143 K compressé) et inclut aussi un algorithme de diff de DOM virtuel.
    On espère pouvoir encore réduire la taille avec d’autres optimisations, par exemple en diminuant le nombre de variables locales ou en adoptant la proposition de stack switching.
    Les problèmes liés à cela sont récapitulés ici.

• woot (brève exclamation)

• C’est exactement ce à quoi JavaScript était censé ressembler à l’origine.
  Si Netscape n’avait pas imposé une syntaxe de style C/Java, le langage aurait peut-être évolué dans cette direction.