This was a nice little experience report. Most of the deficiencies in Hoot can be blamed on me.
> 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.
Spritely has been going strong for many years. I suppose Hoot was created to make Goblins [0] available to a broader public via wasm, as a reference implementation of CapTP specification [1]. Wonder what the timeline is, if any exists, for getting this protocol at a maturity level where it is attractive to implement as an open standard.
Hi! Yes, Spritely started Hoot to get Spritely's programs, built on top of Spritely Goblins, to a wider audience. And the network protocol we use / co-designed is OCapN, which is indeed in the family of CapTP languages: https://ocapn.org/
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!
“Spritely has been going strong for many years. I suppose Hoot was created to make Goblins [0] available to a broader public via wasm, as a reference implementation of CapTP specification”
> Lately I've been spending time learning Scheme and using it to implement the concepts I'm learning in my physics classes as time permits.
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
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.
This was a nice little experience report. Most of the deficiencies in Hoot can be blamed on me.
> 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.
Spritely has been going strong for many years. I suppose Hoot was created to make Goblins [0] available to a broader public via wasm, as a reference implementation of CapTP specification [1]. Wonder what the timeline is, if any exists, for getting this protocol at a maturity level where it is attractive to implement as an open standard.
[0] https://spritely.institute/goblins/
[1] https://github.com/ocapn/ocapn/blob/main/draft-specification...
Hi! Yes, Spritely started Hoot to get Spritely's programs, built on top of Spritely Goblins, to a wider audience. And the network protocol we use / co-designed is OCapN, which is indeed in the family of CapTP languages: https://ocapn.org/
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!
The OCapN group is actively working on a milestone for 1.0, the first interop target. It's getting close! https://github.com/ocapn/ocapn/milestone/2
“Spritely has been going strong for many years. I suppose Hoot was created to make Goblins [0] available to a broader public via wasm, as a reference implementation of CapTP specification”
Has extreme Curtains for Zoosha (https://amp.knowyourmeme.com/memes/curtains-for-zoosha) energy
> Lately I've been spending time learning Scheme and using it to implement the concepts I'm learning in my physics classes as time permits.
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].
[0]: https://archive.org/details/oapen-20.500.12657-26048
Direct link to Hoot: https://spritely.institute/hoot/
I don't understand.
Why not just use Scheme directly, what's the benefit of porting to Hoot?
> 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).
Presumably to run in the browser? Guile Scheme is great for native programs but you need Hoot to run it in a browser.
Did you click the link? https://gracefulliberty.com/physics/
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.
I think the second sentence of the article covers that pretty simply? To run it in the browser with wasm?
> One of the most exciting things I've been doing with this is getting my Scheme to compile to the Web thanks to Hoot.
Yes, but why? If the purpose is to run Scheme, run Scheme: why jump through Hoots oops I mean hoops.
> Yes, but why?
Most likely answer is "because that's what they wanted to do", which is a totally legit reason.
How do you run Scheme directly in the browser?
Why would anyone want to run scheme in the browser? That's what I'm trying to understand.
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?
A couple of reasons that come to mind:
- 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.
> Why not just use Scheme directly, what's the benefit of porting to Hoot?
In other terms: Why not just use C directly, why use gcc?
[dead]
[flagged]