WASM
Pebaz opened this issue · 6 comments
Just submitting my interest in having the ability to embed Passerine in a WASM game written in Rust.
Ah, that's pretty neat. Because Passerine doesn't have any deps, it's pretty easy to get it compiling on any architecture supported by Rust - that includes wasm32-wasi and wasm32-unknown-unknown. In fact, here's a screenshot I took the other day of me running passerine + aspen in wasmtime compiled with the wasm32-wasi toolchain:
Note that, however, this is compiling the Compiler + VM to wasm and running that; it's not actually producing wat or wasm binary or anything. Getting Passerine to compile down to wasm is an eventual goal of mine (it's on the roadmap I believe), but we can't compile down to anything lower than the VM until we have type-checking in place.
Another thing about Wasm: I'd like to add a playground to https://passerine.io; everything is in place for this to be possible right now. If anyone wants to experiment with making a web playground for Passerine, let me know.
Speaking of Wasm, I've got Passerine running in the browser. This is static and runs in-browser; we're not calling out to any server-side code:
playground.demo.mov
I still need to add styling and so on, but I've confirmed it's possible to interact with JS from Rust by using the FFI. When we eventually redo https://passerine.io, we'll include this playground. The repo for the playground is https://github.com/vrtbl/playground.
This is amazing, thank you for looking into this!
Cross-referencing this issue here: vrtbl/playground#1. This would require moving hoisting before desugaring, which is good because I think we need to rework the compilation pipeline slightly. Here's my proposal:
- lex
- parse
- desugar (split from macro expansion)
- hoist (move up before expansion)
- expand (split from desugar)
- infer
- gen
And the then we'd also move all the types types for each step into a new module. I'm also thinking of refactoring the way Data, Lambda, and Closure work (reference counting lambdas, moving some data, like Heap and NotInit to the stack/VM). And the way the VM is initialized, and what it returns.
We also need to think about moving the FFI to external algebraic effects - i.e. the FFI is just a effect handler implemented in Rust.
At minimum, we need to remove stamp and nantagging to get Wasm 100% working. The above is later stuff - perhaps I'll open a new issue for that.
I've cleaned up the pipeline wrt the above issues, closing. See #52