> The error messages can be cryptic.
Apologies! Happy to receive issue reports about specific things that we can prioritize.
> It's even more incredible to know that it's running on a stack the team created themselves, not relying on Emscripten.
Building our own toolchain has proven again and again to have been the right choice. Emscripten would not have been useful for compiling Scheme to Wasm GC. Hoot is one of the few Scheme-to-Wasm implementations that takes advantage of the GC support (and the most mature of them all.)
> My initial understanding of Hoot was that it could compile any Guile program to the Web.
This is indeed the goal. However, that's a big compatibility surface area and we are not there yet. Help wanted! When we reach a critical mass of existing Guile code that "just works" then Hoot will be mature enough to become part of Guile itself as its official Wasm backend.
[0] https://spritely.institute/goblins/
[1] https://github.com/ocapn/ocapn/blob/main/draft-specification...
The good news is there are four fairly mature implementations (two Scheme implementations across Guile and Racket, a Dart implementation, a Javascript implementation) and one upcoming one (a Zig implementation). We have a whole specification and test suite and even an implementation guide!
The experience Jessica Tallon and I had with doing standardization work on ActivityPub led us to decide to take a different path when starting the group for OCapN: instead of bringing the topic of what we wanted to achieve to a standards group, we decided to start a "pre-standards group" which, effectively, works pretty much exactly like a standards group but does all the heavy lifting of making sure we have a decent spec, interoperability, a test suite, etc before bringing to a formal standards group (or really moving outside of "stealth mode": we haven't advertised OCapN too much to make sure we had a design that was fairly solid between a few core implementations before trying to push for wider adoption, which can quickly ossify a spec since making changes past that point requires getting the whole ecosystem to change). We've mostly achieved that now, and there's an open debate about whether, should we really bring this to a formal standards group at all?
Regardless, OCapN is pretty awesome, and we'll probably revamp the website and etc pretty soon to make it clearer that it's ready for more projects to start implementing!
Has extreme Curtains for Zoosha (https://amp.knowyourmeme.com/memes/curtains-for-zoosha) energy
There is a whole book for that: Learn Physics with Functional Programming A Hands-on Guide to Exploring Physics with Haskell by Scott N. Walck, December 2022, 648 pp. ISBN-13: 9781718501669
There is also SICM [0].
Why not just use Scheme directly, what's the benefit of porting to Hoot?
Scheme is not a thing you use directly, you have to select an implementation. Hoot is one such implementation (targeting execution on WASM).
They are making little web applets demonstrating the physics concepts. You obviously can't do this in pure R6RS/etc., you need to pick some implementation that either has JS/WASM FFI or something built in. Likewise if they were doing this as a desktop application, etc. Pure Scheme can model the physics and return the correct numbers, but you need something more for graphics and interactivity.
> One of the most exciting things I've been doing with this is getting my Scheme to compile to the Web thanks to Hoot.
Most likely answer is "because that's what they wanted to do", which is a totally legit reason.
If the goal is to run scheme, run scheme. If the goal is to port Hoop then I get it.
Why walk in water when you can take the ferry?
- For the same reasons people run js server-side: single codebase in the same language; familiarity with the language; other?
- Because some people simply like scheme and want to code the frontend of webapps in scheme
- Because they want to port Goblins to the browser and Goblins already work with scheme.
In other terms: Why not just use C directly, why use gcc?