Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by neilv on Wednesday May 31, 2023 @08:45AM
(#36137691)
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.
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by neilv on Wednesday May 31, 2023 @09:59AM
(#36138509)
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
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).
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).
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by bitwize on Wednesday May 31, 2023 @12:29PM
(#36140263)
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.
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by kaba0 on Wednesday May 31, 2023 @01:53PM
(#36141366)
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!
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by schemescape on Wednesday May 31, 2023 @10:24AM
(#36138774)
Tangential question: How interoperable are the top Scheme implementations (Guile. Chez, Chicken, etc.)? Specifically, are libraries (beyond SRFIs) often supported in multiple implementations (similar to Common Lisp)?
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by tmtvl on Wednesday May 31, 2023 @01:08PM
(#36140745)
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.
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by tgbugs on Wednesday May 31, 2023 @02:59PM
(#36142469)
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.
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by zelphirkalt on Thursday June 01, 2023 @05:42AM
(#36149091)
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.
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by abrax3141 on Wednesday May 31, 2023 @10:31AM
(#36138846)
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.]
Re:Directly compiling Scheme to WebAssembly: lambdas, recurs...
by agency on Wednesday May 31, 2023 @06:34PM
(#36145321)
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)
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.
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.
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)
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).
I did some search and didn't find any recent statement on that.
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.
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.
https://github.com/WebAssembly/proposals
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.
https://github.com/schism-lang/schism
Previous discussion with comments by the author, https://news.ycombinator.com/item?id=16488605