biwascheme VS exception-handling

If Scheme is something you enjoy, BiwaScheme's interpreter can be instantiated from within Javascript and can be used to evaluate Scheme code.

https://www.biwascheme.org/

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

For Scheme implementations there are LIPS and biwascheme. I haven't done more than play around with them, so I can't really give an informed opinion about pros and cons or favorites.

I used to have hundreds of open tabs. From there I kept repurposing it to do more stuff with the browser until it reached its current state, where I want to make it a "extend firefox from Emacs" thing. It kinda do that already, but extending the firefox-extension itself require the extension to be re-built (so you need whole javascript tooling, rebuild and reload the addon etc). I am considering adding something like biwascheme to it soon to work around that.

And then users can just use biwascheme and run programs in mainframes and their smart toasters

Languages like Biwa Scheme and LIPS Scheme are good for running Scheme in the browser. But I would prefer compiling Scheme code to JavaScript in the server, then serving the compiled JavaScript image to the browser.

Just a note that even BiwaScheme doesn't fully implement call/cc, it doesn't save the whole environment when capturing.

Very cool! Do you know how this compares with Biwascheme? https://www.biwascheme.org/

Biwascheme has some weird scoping bugs that makes me a litte afraid of using it for serious stuff. It seems nixe and all, but this: https://github.com/biwascheme/biwascheme/issues/125 is not very confidemce inspiring.

There is another schemey language that compiles to JS that accepts things like this:

    (when (start-are-aligned?)

Interesting article, thanks!

Notes on the issues mentioned there:

* The need for a manual shadow stack: This is fixed in WasmGC (in the same way it works in JS, as the link mentions).

* Lack of try-catch: This is fixed by the Wasm exception handling proposal, which has already shipped in browsers, https://github.com/WebAssembly/exception-handling/blob/main/...

* Null checks: Mostly fixed by WasmGC. The spec defines non-nullable local types, and VMs can use the techniques the article mentions to optimize them using signals (Wizard does, for example).

* Class initialization: This is a difficult problem, as the article says. J2Wasm and Binaryen are working to optimize it through static analysis at the toolchain level. Here is a recent PR I wrote that makes progress there: https://github.com/WebAssembly/binaryen/pull/6061

* The vtable overhead issue the article mentions may be a problem. I'm not aware of good measurements on it, through. There are some ideas on post-MVP solutions for method dispatch that might help, but nothing concrete yet.

* Checks for null and trapping: There has been discussion of variants on the GC instructions that throw instead of trap. Measurements, however, have not shown it to be a big problem atm, so it is low priority.

The author is right that stack walking, signals, and memory control are important areas that could help here.

Overall with WasmGC and exceptions we are in a pretty good place for Java as emitted by J2Wasm today: it is usually faster than J2CL which compiles Java to JavaScript. But there is definitely room for improvement.

It uses https://github.com/WebAssembly/exception-handling/blob/master/proposals/exception-handling/Exceptions.md which is actually supported by all major browsers already.

Yep, you're right. It's also more than just the DOM, it's web APIs in general, such as fetch, audio, webgl/webgpu, etc. WASM still needs GC, exceptions, and WASI to be able to fully interop with any host without any of the current limitations. This'll take a few years. I'm looking forward to the future in which I will be shipping WASM-only web apps to my users.

Its a part of the wasm plan to support gc https://github.com/WebAssembly/gc exceptions https://github.com/WebAssembly/exception-handling

As of Node.js 17, the v8 JavaScript engine has been updated to v9.5. The changes in this release are primarily aimed at expanding internationalization for dates and calendars as well as for the output of time zones. It also implements the WebAssembly Exception Handling proposal, designed to reduce overhead compared to current JavaScript-based workarounds.

Agreed, although at some point in a not very far feature most of those missing features will resolved. So in my mind is just a matter of time. The Wasm Community group is doing an awesome work on that :)

Here are a few examples of what needs move forward in Wasm:

* [1] Wasm Exceptions Handling: Right now Wasm is missing a way to handle exceptions natively (C++ programs can only compile to Wasm using the asyncify or longjmp/setjmp tricks via Js try/catch)

* [2] Wasm GC: Wasm Binary files are quite big (specially in interpreted languages). This is partially caused by the GC being included in the Binary itself. The GC proposal will solve this while also providing faster execution.

* [3] Wasm 64-bit Memory: currently Wasm can only operate with 32-bit data. In some contexts you may want you operate with more than 4GB of memory (for example, when operating over terabytes of data). The 64-bit memory proposal will solve that.

[1]: https://github.com/WebAssembly/exception-handling