Discussion summary

A discussion about porting Scheme to Hoot for browser use, with some mentioning its application in physics simulations and web applets. Hoot is seen as a way to run Scheme in browsers via wasm.

What the discussion says

  • Hoot enables Scheme to run in browsers using wasm.
  • Scheme implementations like Guile are better for native programs.
  • Hoot aims to make Scheme more accessible through web apps.
Hoot was created to make Goblins available via wasm.
rapnie
Scheme is not used directly; Hoot is an implementation targeting execution.
Jtsummers

Comments

Hacker News

I don't understand.

Why not just use Scheme directly, what's the benefit of porting to Hoot?

by NordStreamYacht

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.

by wallstop

> 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?

by veqq

Presumably to run in the browser? Guile Scheme is great for native programs but you need Hoot to run it in a browser.

by ryukafalz

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.

by Diogenesian

> 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).

by Jtsummers

> 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

by __rito__

“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

by rao-v

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!

by paroneayea

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.

by davexunit

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I don't understand.

    Why not just use Scheme directly, what's the benefit of porting to Hoot?

    by NordStreamYacht
  • 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.

    by wallstop
  • > 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?

    by veqq
  • Presumably to run in the browser? Guile Scheme is great for native programs but you need Hoot to run it in a browser.
    by ryukafalz
  • 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.

    by Diogenesian
  • > 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).

    by Jtsummers
  • by cpach
  • > 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

    by __rito__
  • 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...

    by rapnie
  • “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

    by rao-v
  • 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
    by davexunit
  • 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!

    by paroneayea
  • 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.

    by davexunit

Related stories