WebAssembly’de Çalışan Scheme — Hoot Projesi

 (spritely.institute)
2 puan yazan GN⁺ 2026-02-09 | 1 yorum | WhatsApp'ta paylaş
  • Scheme kodunu WebAssembly(GC destekli tarayıcılarda) çalıştırmak üzere tasarlanmış bir proje olup, bir Scheme→Wasm derleyicisi ve eksiksiz bir Wasm araç zinciri içerir
  • GNU Guile tabanlı olarak inşa edilmiştir, ek bağımlılık gerektirmez ve kendine yeterli (self-contained araç zinciri) bir yapıya sahiptir
  • Guile REPL ortamında Wasm yorumlayıcısı üzerinden Hoot ikililerini test etmek mümkündür
  • En güncel sürüm v0.7.0 olup, sürüm dosyaları, imzalar, belgeler ve resmî duyuru bağlantısı sunulur
  • Scheme dilini web ortamına genişletme girişimi olarak, tarayıcı tabanlı Lisp ekosisteminin genişleme potansiyelini gösterir

Hoot genel bakış

  • Hoot, Spritely Institute tarafından geliştirilen ve Scheme kodunu WebAssembly(Wasm) üzerinde çalıştırılabilir hale getiren bir projedir
    • GC(Garbage Collection) özelliğini destekleyen web tarayıcılarında çalışır
    • Scheme kodunu Wasm’a dönüştüren bir derleyici ve Wasm ile ilgili geliştirme için eksiksiz bir araç zinciri içerir
  • Guile üzerine kuruludur ve ek harici bağımlılığı yoktur
    • Araç zinciri kendi içinde tamamlanmıştır ve Wasm yorumlayıcısını gömülü olarak barındırır; böylece Guile REPL içinde Hoot ikilileri doğrudan test edilebilir

Dağıtım ve geliştirme

  • En son sürüm v0.7.0’dır; indirme dosyaları, imzalar, belgeler ve resmî duyuru bağlantısı sağlanır
    • Sürüm dosyası: guile-hoot-0.7.0.tar.gz
    • Belge ve imza dosyaları ile ilgili haber sayfası birlikte sunulur
  • Geliştirme sürümüne Codeberg deposundan erişilebilir (https://codeberg.org/spritely/hoot)

İlgili kaynaklar

  • Hoot ile etkileşimli web sayfaları oluşturma örnekleri ve tarayıcı içinde Scheme çalıştırma ile ilgili çeşitli yazılar sunulur
    • “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’nun blogu ve System Crafters röportaj videosu üzerinden geliştirici bakış açısından ek bilgiler edinilebilir

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-09
Hacker News yorumları

  • Son zamanlarda Guile geliştirmesinin yeniden hızlanması ilginç.
    Yine de eski Racket topluluğundan epey kişinin buraya kayıyor gibi görünmesi biraz üzücü.
    Topluluğun bölünmesi üzücü bir şey ve Guile’ın hâlâ performans ile kütüphane çeşitliliği açısından Racket’in gerisinde olduğu hissi var.

    • Benim deneyimimde tam tersi oldu. Guile’ın başlangıç hızı Racket’ten daha iyiydi ve yaptığım işlerin çoğu I/O ağırlıklı olduğu için Guile daha uygundu.
      Benchmark’lar farklı sonuç verebilir ama doğrudan denemek gerekir gibi görünüyor.
    • Guile şu anda bytecode VM + JIT yapısında olduğu için Chez/Racket’ten daha yavaş, ama yine de oldukça hızlı.
      60fps hızında oyun çalıştırabilecek kadar iyi ve GC de seyrek tetikleniyor.
      Eskiye kıyasla kütüphane ekosistemi de çok gelişti.
    • Eskiden Racket topluluğunda bir “Missing Stair” sorunu olduğuna dair bir blog yazısı okuduğumu hatırlıyorum.
      (Missing Stair wiki)
      O olaydan sonra topluluğun bölünmesi kaçınılmaz bir sonuç gibi görünüyor.
    • Guile’ın ilgi görmesi sevindirici ama Racket’i küçümsememek lazım.
      • Guile’ın WASM çalışmaları umut verici ve Racket tarafında da Jens Axel Soegaard ilgili bir derleyici geliştiriyor.
      • Racket’in Chez tabanlı yeniden barındırılması iyi bir tercih gibi görünüyor ve iç yapısı da muhtemelen Guile’dan daha kolay ele alınır hale gelmiştir.
      • Racket hâlâ metaprogramlama ve modül sistemi tarafında güçlü.
        Örneğin Overeasy ile testler, McFly ile de belgeler satır içine yazılabiliyor.
      • Scheme ailesi hâlâ “iş bulma anahtar kelimeleri”ni dert etmek zorunda olmayan insanların dili olarak kalıyor.
        Son dönemde AI kod üretimi ve VC yatırımlarındaki çöküş sonrasında sektörün daha da zorlaşması da bunda etkili.
    • Guile’ın başka bir uygulaması olan Hoot’un (örneğin V8 üzerinde çalışan) benchmark’ı yapıldı mı diye merak ediyorum.

  • Projenin kendisi harika ama keşke Guile yerine başka bir dil kullanılsaydı diye düşünüyorum.

    • Yine de Guile, Guix’in dili olduğu için ekosistemi zengin.
      Guix sayesinde yeniden üretilebilir build’ler kolayca oluşturulabiliyor.
      Ama debugger, macro expander ve R6RS standart kütüphanesi ile ilgili sorunlar hâlâ duruyor.
      Racket’in çok çekirdek desteği eskiden hantaldı ama Guile’daki fibers/futures ile karşılaştırıldığında artık iyileşmiş gibi görünüyor.
    • Guile yerine başka bir Scheme uygulaması kullanalım deniyorsa, R6RS/R7RS standart sözdizimi kullanıldığında taşınabilirlik çok zor olmaz.

  • WASM’a derleme yönündeki böyle girişimlerin yeniden ortaya çıkması sevindirici.
    Eskiden heyecanı sönmüş sanıyordum ama bu tür diller çoğalırsa JavaScript’ten kaçınabilmek güzel olur.

  • Bu proje bana gelecekte programlama dillerinin yönünü düşündürdü.
    AI kodun başlıca yazarı olursa, diller büyük olasılıkla açıklık ve hata azaltma etrafında şekillenecek.
    İnsanlar için daha az eğlenceli ama düzeltmesi daha kolay kod ortaya çıkacak.
    Bu bağlamda Rust gibi dillerin üst sıralarda yer alacağını düşünüyorum.
    Yine de Hoot gibi bir dilin uzmanlık alanlarında da yer edinip edinemeyeceğini, yoksa bir hobi dili olarak mı kalacağını merak ediyorum.

    • Ben de AI odaklı dillerin nasıl görüneceğini düşünüyordum; muhtemelen Scheme/Lisp ailesi bu yöne daha yakın olacaktır.

  • Gerçekten çok havalı! Acaba Cloudflare Workers üzerinde de çalışabilir mi?

  • Keşke Guile’ın Windows desteği biraz daha iyi olsa.

  • repl.wasm 1.6MiB, biraz büyük görünüyor. todo örneğinin boyutu ne kadar acaba?

    • Bu REPL en küçük binary değil ama gzip ile sıkıştırıldığında 339K’ya düşüyor.
      Henüz wasm-opt optimizasyonu da uygulanmış değil.
      Hoot bir AOT derleyicisi olduğu için REPL’e macro expander, çalışma zamanı modül sistemi, interpreter gibi ek kodlar da dahil ediliyor.
      Gerçek örnek olan todo.wasm yaklaşık 566K (sıkıştırılmış halde 143K) ve içinde sanal DOM diff algoritması da var.
      Yerel değişken sayısını azaltmak ya da stack switching önerisini benimsemek gibi ek optimizasyonlarla boyutun daha da küçülebileceği umuluyor.
      İlgili konu burada derlenmiş.

  • woot (kısa bir sevinç ifadesi)

  • İşte JavaScript’in aslında yönelmek istediği şey buydu.
    Netscape C/Java tarzı sözdizimini dayatmamış olsaydı, belki de böyle bir dil olurdu.