Whalesong used the built-in bytecode compiler and compiled the bytecode to JavaScript. Reusing the bytecode compiler is in principle a good idea - but each time the bytecodes are changed, Whalesong needs to be updated.
And after the move to Chez Scheme as backend, the bytecode compiler is no longer a part of the main compilation path.
I read the WASM spec and became somewhat of an expert in it for the purpose of eventually designing a low-level language specifically for wasm, to be the most efficient and lowest-level language you could possibly have for wasm, and then gradually add high level concepts into it to make it more convenient. Kind of like building C on top of asm, and then gradually evolving it into C++. That project never came about though due to lack of community interest and time on my part, but I like seeing languages that take a fresh look at how to integrate with wasm using novel techniques to aim for maximal efficiency.
> to be the most efficient and lowest-level language you could possibly have for wasm, and then gradually add high level concepts into it to make it more convenient. Kind of like building C on top of asm, and then gradually evolving it into C++. That project never came about though due to lack of community interest and time on my part, but I like seeing languages that take a fresh look at how to integrate with wasm using novel techniques to aim for maximal efficiency.
I wonder how much efficient would such wasm be compared to native itself theoretically?
I really like libriscv as well, what are your thoughts on libriscv and now the recent project created by legendary fwsgonzo about looongarch.
Although I would say that libriscv/loongarch are more focused on trying to start the fastest as much as possible instead of pure performance (for which if atleast for the purpose of sandboxing, fwsgonzo has also created tinykvm which is really quite close to native performance)
Speaking of prolific Racketeers... Noel! Just an hour ago, on a walk, I was thinking, "I should work through that one LLM book, and implement it in Racket." (But have started job-hunting, so will probably be Python.)
I've got so much other stuff I'd rather learn and code I'd rather write (C/wasm backend for my language), but I've also started job hunting and probably should understand how this latest fad works. Neural networks have long been on my todo list anyway.
It is interesting to see another language target WebAssembly especially one like Racket. The fact that it compiles to a subset of the language limits its utility right now. I think it is a neat proof of concept but it needs full language support.
For folks curious about the supported language subset, here's a summary:
- Modules aren't implemented yet, but are high on the list
- Continuation-based control flow isn't supported yet, including break and promises. Tail calls are supported though.
- No support for complex numbers, bignums, weak hashtables, immutable hashtables, prefab structs, regexp, or file I/O support
Most of the rest of racket/base should work, according to the README. There's also a FFI for javascript, including bindings for Math, DOM, Canvas, MathJax, XTermJS, and JSXGraph. Overall feels like you can use most of the language right now unless you need odd Racket-isms or call/cc.
You could probably model continuations using the wasm GC feature since you can then pass around function references and strongly typed continuation objects, but making it work certainly wouldn't be trivial.
Of course both projects have the same maintainer if I recall, Jens Axel Søgaard is a rockstar :)
Whalesong used the built-in bytecode compiler and compiled the bytecode to JavaScript. Reusing the bytecode compiler is in principle a good idea - but each time the bytecodes are changed, Whalesong needs to be updated.
And after the move to Chez Scheme as backend, the bytecode compiler is no longer a part of the main compilation path.
Original developer of Whalesong was Danny Yoo. https://www.hashcollision.org/whalesong/
There was also this: https://docs.racket-lang.org/racketscript/
Dave Herman worked on various JS-related libraries for Racket (or PLT Scheme) before he was involved with Rust.
I wonder how much efficient would such wasm be compared to native itself theoretically?
I really like libriscv as well, what are your thoughts on libriscv and now the recent project created by legendary fwsgonzo about looongarch.
Although I would say that libriscv/loongarch are more focused on trying to start the fastest as much as possible instead of pure performance (for which if atleast for the purpose of sandboxing, fwsgonzo has also created tinykvm which is really quite close to native performance)
I've got so much other stuff I'd rather learn and code I'd rather write (C/wasm backend for my language), but I've also started job hunting and probably should understand how this latest fad works. Neural networks have long been on my todo list anyway.
- Modules aren't implemented yet, but are high on the list
- Continuation-based control flow isn't supported yet, including break and promises. Tail calls are supported though.
- No support for complex numbers, bignums, weak hashtables, immutable hashtables, prefab structs, regexp, or file I/O support
Most of the rest of racket/base should work, according to the README. There's also a FFI for javascript, including bindings for Math, DOM, Canvas, MathJax, XTermJS, and JSXGraph. Overall feels like you can use most of the language right now unless you need odd Racket-isms or call/cc.