WASM

[Pebaz]

Just submitting my interest in having the ability to embed Passerine in a WASM game written in Rust.

[slightknack]

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.

[slightknack]

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.

[slightknack]

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:

https://user-images.githubusercontent.com/54823450/113659775-0b65f900-96a3-11eb-925d-a4edbeab9973.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.

[Pebaz]

This is amazing, thank you for looking into this!

[slightknack]

Cross-referencing this issue here: https://github.com/vrtbl/playground/issues/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.

[slightknack]

I've cleaned up the pipeline wrt the above issues, closing. See #52