Web-based "playground"/JSFiddle experience

[regular]

Are there plans or ongoing efforts to port the compiler/interpreter itself to WASM so it could be embedded on a web page?
This would be a great feature to get into the language more quickly. It would make sure that examples in online tutorials are actually correct, and readers could run examples in the browser with a simple click on a "Run" button and tinker with the code.

Could GHC's wasm backend help here?

The final goal should be a compiler that runs in a wasm environment and that generates wasm code.

Any thoughts?

[hatemhosny]

If a wasm compiler is available, I would be happy to add support for koka in LiveCodes (an open-source, client-side code playground for that supports 90+ languages and frameworks).

See starter templates

Projects can be shared, exported (e.g. GitHub gist), deployed (to GitHub Pages) and embedded in web pages.

See docs for more details.

Please let me know if you are interested.

[TimWhiting]

Great idea, I actually could maybe use this in a class I'll be teaching. I'll look into GHC's wasm backend for the compiler, but I don't think we'll be able to generate wasm initially, since we'd need a C compiler that works online (we don't directly generate wasm right now). I think this is doable, but it seems better to use Koka's JS backend, and then just create a direct wasm backend, so we don't have to deal with a C compiler bloating the web download.

[TimWhiting]

It looks like both the JS and WASM GHC backends require custom ghc builds, and are not well integrated into the stack build system, which makes it difficult for me to get started with this. I'm inclined to wait until it makes it into a nightly stack resolver. Alternatively, I'm more inclined to continue work on the self-hosted Koka compiler I started awhile back, which we could then compile to js/wasm. A first step there is to get enough of it working to support #521, which I think is actually pretty close.

Some notes: with regards to the JS backend, we would also need to remove some libraries (for the command line interpreter) probably from the core koka package.

[regular]

@TimWhiting so, you are working on a Koka compiler written in Koka with a wasm backend that is able to compile itself to wasm? That would be the most elegant path forward, I agree!

[regular]

Some notes: with regards to the JS backend, we would also need to remove some libraries (for the command line interpreter) probably from the core koka package.

Maybe not, if you target WASI, which makes sense anyway, since WASM/WASI are considered (by some) to become the standard for an architecture-agnostic executable format (sort of like what Java once promised). What I mean to say: WASM is not only interesting in the browser context, and much more relevant these days than JS (at least in terms of compilation targets)