Directly compiling Scheme to WebAssembly: lambdas, recursion, iteration | Hacker News Reader

Directly compiling Scheme to WebAssembly: lambdas, recursion, iteration

spritely.institute

142 pointsrekado23 comments

It is worth checking out other stuff that has come out of spritely institute as well:

There was something about a distributed debugger [1]. Also look at a talk about Goblins itself [2].

[1]: https://spritely.institute/news/introducing-a-distributed-de...

[2]: https://invidious.baczek.me/watch?v=VyTlQ0zwIAM (VyTlQ0zwIAM)

This is very promising. Years ago, I was thinking that probably Racket, Gambit, or someone's dissertation would evolve into production-grade Wasm target. But looks like Andy Wingo, et al., are really tackling it through Guile.

I built rasm (https://github.com/GrantMatejka/rasm) to compile racket to wasm. Definitely not production grade, but fun nonetheless

Projects like these are great, and absolutely in traditions of Scheme, PL research, hobbies/learning, and sometimes startups.

Not everything has to be overtly adopted to be worth doing.

Historically, when someone makes some advancement that doesn't lead to adoption, it seems often because:

* there's no follow-through to production-grade (maybe the norm with PL dissertations, if the next job isn't industry and directly involving that same platform);

* the market applicability is too niche/nonexistent, at least at the time (e.g., someday people will realize better DSLs were figured out a long time ago); or

* didn't promote it well enough.

https://github.com/google/schism

For some reason, Google was working on a Scheme WASM compiler, which they got self-hosting. It was then abandoned. I don't really know what they were trying to accomplish with that project.

This was a personal project of a then-Googler, not a Google project.

https://github.com/schism-lang/schism

Previous discussion with comments by the author, https://news.ycombinator.com/item?id=16488605

Tangential question: How interoperable are the top Scheme implementations (Guile. Chez, Chicken, etc.)? Specifically, are libraries (beyond SRFIs) often supported in multiple implementations?

Bumping. Would be deeply interested too.

I did some search and didn't find any recent statement on that.

There are some that run on generic R[67]RS, but many libraries tend to target a specific implementation (chicken with its eggs, all the guile-whatever libraries). You can check out Akku (akkuscm.org) or Snow for Scheme-oriented package managers.

It will depend on which implementation specific behavior a given library uses. For example, guile has `#{}#` syntax for verbatim atoms. If a library uses that it will not work on any other scheme. Guile and gambit also have divergent behavior when e.g. parsing char literals `#\)a` parses correctly in guile but not gambit, and on the other hand `'a'b'c` reads as `c` in gambit but `a'b'c` in guile. And these are just issues with variant behavior in the reader.

The list of these kinds of edge cases is long so it probably winds up being easier to try to just run a library to see if it works. I doubt anyone has done a systematic survey.

There are often libraries specific to the Scheme one uses, either built-in or external but easy to install. When writing code one has the choice of picking the one that is specific for the Scheme dialect, or trying to get by by using SRFIs (Scheme Request For Implementation). When using SRFIs, there is a good chance, that they are also available in another Scheme. Perhaps one has to change how things are imported a little. At least for popular SRFIs. However, often (maybe this is a requirement for a SRFI? idk) there will also be an example implementation given with the SRFI, which might allow for easy porting to the Scheme one uses.

I once ported a library I wrote in Racket from Racket to GNU Guile. Since I made use of Racket's for loop forms, I had to rewrite those parts using different constructs like named let in GNU Guile. That was most of the work. I also had to changed how it makes use of multiple cores (places -> futures), but that is to be expected, I guess.

As others have stated, it depends on the code you are porting. If you do not have many dependencies and made a choice to use mostly standard Scheme constructs, you will have not much of a problem to port it to another Scheme.

Last I checked WASM did not yet allow tail jumps. Without these compiling Scheme would be very clumsy. Has this been resolved?

It's being supported in an extension that looks on track to be broadly available across WASM runtimes soonish.

The proposal was recently bumped to stage 4 (the penultimate stage) with at least a couple of runtimes working on implementing (besides v8, which has supported it for quite awhile now)

https://github.com/WebAssembly/proposals

All day I push out js for a paycheck, all night I live and tinker in my Lisp/scheme worlds. Maybe one day these will be overlayed.

This project is very exciting. In the meantime, there are a couple of options:

BiwaScheme: https://www.biwascheme.org/

Advantages: written in JavaScript, with excellent JS interop. Project has some history.

Disadvantages: slower than S7 (though still plenty fast for many uses), less-complete (e.g., no syntax-rules or syntax-case, though it does have its own define-macro).

S7 Scheme: https://cm-gitlab.stanford.edu/bil/s7

Written in C, but can be transpiled to WASM (see https://github.com/actonDev/s7-playground/ )

Advantages: This project also has some history. Considerably faster than BiwaScheme.

Disadvantages: JS interop is clumsier (basically the same issues as JS interop with any WASM code... this could probably be mitigated considerably if someone wanted to take the time).

Gambit has a JavaScript compilation target backend. It works really well. The runtime code you need to run JS-compiled Gambit code is large, but compared to the neutron-star density of most projects' node_modules it's utterly manageable. It's a little harder to justify on the front end though.

ClojureScript? I hear it is a really great guest language that fits within its respective host ecosystem very nicely (though I have mostly used it on the JVM), but the underlying library that converts it to JS is very battle-tested and produces great code!

I did fairly standard web dev and devops for 10 years before finding work at a Lispy place. Best of luck to you!!

As soon as I saw WAT I've wondered whether a series of transformations from a Scheme would end up efficient. I'm glad someone proved it.

Ahhhh! A breath of fresh air in this world of ugly Algol-wedged hyper-utilitarianism. (I was going to say “hyper-functionalism”, but the unintended pun confused the sense.) [Although, I must admit that js is actually pretty descent, and can almost be used like Lisp if you look at it hard enough and cross-eyed.]

JavaScript was originally meant to be a Scheme dialect, but corporate people wanted it to look more like Java.

Yes. And, once more with feeling: https://xkcd.com/297/

Reply on news.ycombinator.com