WebAssemblyで動作するScheme — Hootプロジェクト

 (spritely.institute)
2 ポイント 投稿者 GN⁺ 2026-02-09 | 1件のコメント | WhatsAppで共有
  • Schemeコードを WebAssembly（GC対応ブラウザ） 上で実行できるように設計されたプロジェクトで、Scheme→Wasm コンパイラと完全なWasmツールチェーンを含む
  • GNU Guileベースで構築されており、追加依存関係がなく、自己完結型のツールチェーン構造を持つ
  • Guile REPL環境で Wasmインタープリタを通じてHootバイナリをテスト可能
  • 最新版は v0.7.0 で、リリースファイル・署名・ドキュメント・公式発表リンクが提供されている
  • Scheme言語をWeb環境へ拡張しようとする試みであり、ブラウザベースのLispエコシステム拡張の可能性を示している

Hoot概要

  • Hootは Spritely Institute が開発したプロジェクトで、Schemeコードを WebAssembly（Wasm） 上で実行可能にする
    • GC（Garbage Collection）機能をサポートするWebブラウザで動作
    • SchemeコードをWasmに変換する コンパイラ と、Wasm関連開発のための 完全なツールチェーン を含む
  • Guile 上に構築されており、追加の外部依存関係はない
    • ツールチェーンは自己完結しており、Wasmインタープリタ を内蔵し、Guile REPLでHootバイナリを直接テストできる

配布と開発

  • 最新リリースは v0.7.0 で、ダウンロードファイル、署名、ドキュメント、公式発表リンクが提供されている
    • リリースファイル: guile-hoot-0.7.0.tar.gz
    • ドキュメントと署名ファイル、および関連ニュースページもあわせて提供
  • 開発版は Codeberg リポジトリで参照可能 (https://codeberg.org/spritely/hoot)

関連資料

  • Hootを活用した インタラクティブなWebページ構築 事例や、ブラウザ内でのScheme実行 に関する記事が多数紹介されている
    • “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”
  • Andy Wingoのブログ と System Craftersのインタビュー動画 を通じて、開発者視点の追加情報も確認できる

関連記事

1件のコメント

 
GN⁺ 2026-02-09
Hacker Newsの意見

  • 最近 Guile の開発が活発になっているのは興味深い
    ただ、以前の Racket コミュニティの人たちがかなり移ってきているようで、少し残念でもある
    コミュニティが分裂するのは悲しいことだし、Guile は依然として Racket より 性能 や ライブラリの多様性 の面で見劣りする印象がある

    • 私の経験ではむしろ逆だった。Guile は Racket より 起動速度 が速く、私の作業のほとんどは I/O 中心 なので Guile のほうが良かった
      ベンチマークでは違う結果が出るかもしれないが、実際に確認してみる必要がありそうだ
    • Guile は現在 バイトコード VM + JIT 構成なので Chez/Racket よりは遅いが、かなり高速ではある
      60fps でゲームを動かせる程度で、GC もめったに発生しない
      以前より ライブラリエコシステム もかなり良くなっている
    • 以前、Racket コミュニティで 「Missing Stair」問題 があったというブログ記事を読んだ記憶がある
      (Missing Stair Wiki)
      あの事件の後にコミュニティが分裂したのは避けられない結果だったように見える
    • Guile が注目されるのはうれしいが、Racket を過小評価すべきではない
      • Guile の WASM への取り組み は有望で、Racket 側でも Jens Axel Soegaard が関連コンパイラを開発中だ
      • Racket の Chez ベースの再ホスティング は良い選択に見えるし、内部構造も Guile より扱いやすくなっているはずだ
      • Racket は今でも メタプログラミング と モジュールシステム が強みだ
        たとえば Overeasy でテストを、McFly でドキュメントをインラインで書ける
      • Scheme 系は依然として、「就職向けキーワード」を気にしなくてよい人たちの言語のままだ
        最近の AI コード生成 と VC 投資の崩壊 以降、業界の空気がさらに厳しくなったことも影響している
    • Guile の別実装である Hoot（たとえば V8 上で動くもの）がベンチマークされたことがあるのか気になる

  • プロジェクト自体は素晴らしいが、Guile ではなく別の言語を使ってほしかったという気持ちもある

    • それでも Guile は Guix の言語なので、エコシステムが豊かだ
      Guix を通じて 再現可能なビルド を簡単に作れる
      ただし デバッガ, マクロエクスパンダ, R6RS 標準ライブラリ に関する問題は依然として残っている
      Racket のマルチコア対応は以前は重かったが、Guile の fibers/futures と比べても今は改善されているようだ
    • Guile ではない別の Scheme 実装を使おうという話なら、R6RS/R7RS 標準文法 を使えば移植は難しくない

  • WASM にコンパイル するこういう試みがまた出てきてうれしい
    以前は熱が冷めたのかと思っていたが、こういう言語が増えれば JavaScript を避けられる ので良い

  • このプロジェクトを見て、未来の プログラミング言語の方向性 を考えさせられた
    AI が主なコード作成者になるなら、言語は 明確さとエラー削減 を重視する方向に変わっていく気がする
    人間にとってはあまり面白くなくても、修正しやすいコードになるだろう
    その文脈では Rust のような言語が上位を占めそうだ
    ただ Hoot のような言語が専門領域でも地位を築けるのか、それとも 趣味用の言語 にとどまるのかは気になる

    • 私も AI 中心の言語 がどんな姿になるのか気になっていたが、おそらく Scheme/Lisp 系 がその方向に近いのではないかと思う

  • 本当にすごい！ もしかして Cloudflare Workers でも動くだろうか

  • Guile が Windows 対応 をもう少し強化してくれたらいいのにと思う

  • repl.wasm が 1.6MiB なので少し大きめに感じる。todo の例はどれくらいなのだろう

    • この REPL は最小のバイナリではないが、gzip 圧縮で 339K まで縮む
      まだ wasm-opt による最適化も適用されていない
      Hoot は AOT コンパイラ なので、REPL にはマクロエクスパンダ、ランタイムモジュールシステム、インタプリタなどの追加コードが含まれている
      実際の例である todo.wasm は 566K（圧縮時 143K）ほどで、仮想 DOM diff アルゴリズム も含まれている
      追加の最適化でローカル変数の数を減らしたり、stack switching proposal を採用したりすれば、さらに小さくできると期待している
      関連 issue は こちら にまとまっている

  • woot（短い感嘆表現）

  • これこそ JavaScript が本来目指していた姿だった
    Netscape が C/Java 風の文法を押しつけていなければ、こういう言語になっていたかもしれない