So the idea would be Currently, the process is Guile -> Hoot -> WASM But, once Hoot becomes part of Guile itself, you could possibly do Guile -> Hoot -> LLVM or Guile -> Hoot -> C or Guile -> Hoot -> Cranelift or whatever. So Hoot could become a way to convert Guile bytecode to different possible backends Does that sound about right? ________________________________ From: Thompson, David <[email protected]> Sent: Friday, October 24, 2025 4:04 PM To: Srayan Jana <[email protected]> Cc: Guile User <[email protected]>; guile-devel <[email protected]> Subject: Re: What's the future of Guile + Hoot?
Hey Srayan, On Fri, Oct 24, 2025 at 6:39 PM Srayan Jana <[email protected]> wrote: > > I was talking to people in the Lisp Discord (https://discord.gg/WUSUuA5VAu), > and I said the following about Guile and Hoot. However, I don't want to > spread misinformation, so please correct me if I'm wrong > > ``` > Yeah guile isn’t portable > Having talked to some of the maintainers, seems like the plan is to switch > over to hoot/wasm as the backend for guile > Since that’s much more portable and also some of the guile people work on the > WASM standard I think > basically > GNU Guile native scripts and GNU Lightning are not going away, they will > still be native > but to actually redistribute them as standalone binaries and stuff, wasm is > probably going to be the way to go > so like, if you want to package up your Guile script and not rely on a > preexisting runtime on your computer, you'll need to use Guile Hoot instead, > I hope that makes sense > ``` > I believe that's the intention of the people working on Guile and Hoot, > especially since Mr. Wingo has been working on a WASM to C translation > backend for Guile Hoot specifically (https://codeberg.org/andywingo/wastrel) Guile has not adopted any official strategy as to how standalone native binary compilation will be achieved. Andy's wastrel project is a personal interest AFAIK and is not directly associated with Guile nor Hoot, though it borrows Hoot's Wasm toolchain. Personally, I don't see why we wouldn't want to take a more direct approach and compile from CPS to native code rather than going through Wasm first. Hoot's compiler pipeline up to the point where we start manipulating CPS for Wasm-specific reasons can be reused for this purpose. There's also another path where we could compile a statically linked binary that bundles the Guile VM + all the necessary bytecode. Regarding Hoot, our hope for the future is that it can become part of Guile rather than something on the side. Hope this helps clears things up, - Dave
