Scheme executado em WebAssembly — projeto Hoot

• Projeto projetado para executar código Scheme em WebAssembly (navegadores com suporte a GC), incluindo um compilador Scheme→Wasm e uma cadeia de ferramentas Wasm completa
• Construído com base no GNU Guile, sem dependências adicionais, com uma estrutura autossuficiente (toolchain self-contained)
• É possível testar binários do Hoot por meio de um interpretador Wasm no ambiente REPL do Guile
• A versão mais recente é a v0.7.0, com links para arquivos de release, assinaturas, documentação e anúncio oficial
• Como tentativa de expandir a linguagem Scheme para o ambiente web, o projeto mostra o potencial de ampliar o ecossistema Lisp no navegador

---

Visão geral do Hoot

• Hoot é um projeto desenvolvido pelo Spritely Institute para permitir a execução de código Scheme sobre WebAssembly (Wasm)
  • Funciona em navegadores que oferecem suporte ao recurso de GC (Garbage Collection)
  • Inclui um compilador que converte código Scheme em Wasm e uma cadeia de ferramentas completa para desenvolvimento relacionado a Wasm
• É construído sobre o Guile e não possui dependências externas adicionais
  • A toolchain é autossuficiente e incorpora um interpretador Wasm, permitindo testar diretamente binários do Hoot no REPL do Guile

Distribuição e desenvolvimento

• A release mais recente é a versão v0.7.0, com arquivos para download, assinaturas, documentação e link para o anúncio oficial
  • Arquivo de release: guile-hoot-0.7.0.tar.gz
  • Também são fornecidos arquivos de documentação e assinatura, além da página de notícias relacionada
• A versão de desenvolvimento pode ser acessada no repositório do Codeberg (https://codeberg.org/spritely/hoot)

Materiais relacionados

• São fornecidos vários artigos sobre criação de páginas web interativas com Hoot e execução de Scheme no navegador
  • “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”
• Também é possível obter mais informações, na perspectiva de desenvolvedores, por meio do blog de Andy Wingo e do vídeo de entrevista do System Crafters

[GN⁺]

Comentários no Hacker News

• É interessante ver o desenvolvimento recente do Guile ficando mais ativo
  Mas é uma pena que pareça que muita gente da antiga comunidade do Racket esteja migrando para lá
  É triste quando uma comunidade se divide, e o Guile ainda parece ficar atrás do Racket em desempenho e variedade de bibliotecas

  • Pela minha experiência, foi justamente o contrário. O Guile inicia mais rápido que o Racket e, como a maior parte do que eu faço é mais centrado em I/O, o Guile funcionou melhor para mim
    Os benchmarks podem mostrar outra coisa, mas parece algo que vale a pena verificar diretamente
  • O Guile atualmente tem uma estrutura de VM de bytecode + JIT, então é mais lento que Chez/Racket, mas ainda assim é bem rápido
    Dá para rodar jogos a 60fps, e o GC também acontece raramente
    O ecossistema de bibliotecas também melhorou bastante em relação ao passado
  • Lembro de ter visto no passado um post de blog sobre um problema de “Missing Stair” na comunidade do Racket
    (wiki de Missing Stair)
    Depois daquele incidente, a divisão da comunidade parece ter sido um resultado inevitável
  • Fico feliz que o Guile esteja recebendo atenção, mas também não dá para subestimar o Racket
    • O trabalho de WASM do Guile é promissor, e no lado do Racket Jens Axel Soegaard também está desenvolvendo um compilador relacionado
    • O rehosting baseado em Chez do Racket parece uma boa escolha, e sua estrutura interna provavelmente ficou mais fácil de lidar do que a do Guile
    • O Racket continua tendo como pontos fortes a metaprogramação e o sistema de módulos
      Por exemplo, com Overeasy dá para escrever testes, e com McFly dá para escrever documentação inline
    • A família Scheme continua sendo uma linguagem para quem ainda pode se dar ao luxo de não se preocupar com “palavras-chave de empregabilidade”
      O clima no setor também ficou mais difícil recentemente, depois da geração de código por IA e do colapso dos investimentos de VC
  • Fico curioso se a outra implementação do Guile, o Hoot (por exemplo, rodando sobre V8), já foi benchmarkada

• O projeto em si é muito legal, mas fico pensando que seria melhor se usasse outra linguagem que não o Guile

  • Ainda assim, o Guile é a linguagem do Guix, então tem um ecossistema rico
    Com o Guix, é fácil criar builds reproduzíveis
    Mas ainda restam problemas relacionados ao depurador, ao expansor de macros e à biblioteca padrão R6RS
    O suporte a multicore do Racket antes era pesado, mas comparado aos fibers/futures do Guile, parece ter melhorado agora
  • Se a ideia é usar outra implementação de Scheme que não seja Guile, então com a sintaxe padrão R6RS/R7RS a portabilidade não deve ser difícil

• Fico feliz de ver esse tipo de tentativa de compilar para WASM aparecendo de novo
  Achei que o entusiasmo por isso já tivesse esfriado, mas se mais linguagens assim surgirem, ótimo, porque isso permite evitar JavaScript

• Esse projeto me fez pensar sobre a direção futura das linguagens de programação
  Se a IA se tornar a principal autora de código, acho que as linguagens vão mudar para priorizar clareza e redução de erros
  Serão menos divertidas para humanos, mas o código será mais fácil de corrigir
  Nesse contexto, linguagens como Rust provavelmente vão ocupar o topo
  Mas fico curioso se uma linguagem como Hoot pode conquistar espaço mesmo em áreas especializadas, ou se vai continuar sendo uma linguagem de hobby

  • Eu também fiquei curioso sobre como seria uma linguagem centrada em IA, e acho que provavelmente algo da família Scheme/Lisp estaria mais próximo dessa direção

• Muito legal! Será que isso também pode rodar no Cloudflare Workers?

• Queria que o Guile tivesse um suporte melhor a Windows

• repl.wasm tem 1.6MiB, então parece um pouco grande. Fico curioso para saber quanto ficaria o exemplo todo

  • Esse REPL não é o menor binário possível, mas com compressão gzip ele cai para 339K
    Ainda nem foi aplicada a otimização com wasm-opt
    O Hoot é um compilador AOT, então o REPL inclui código extra como expansor de macros, sistema de módulos em tempo de execução, interpretador etc.
    O exemplo real todo.wasm fica em torno de 566K (143K comprimido) e também inclui um algoritmo de diff de DOM virtual
    Espera-se que otimizações adicionais, como reduzir o número de variáveis locais ou adotar a proposta de stack switching, possam diminuir ainda mais o tamanho
    As issues relacionadas estão reunidas aqui

• woot

• Isso é exatamente o que o JavaScript originalmente pretendia ser
  Se a Netscape não tivesse forçado uma sintaxe no estilo C/Java, talvez tivesse virado uma linguagem assim