Joey Hess: Haskell webassembly in the browser
live demo As far as I know this is the first Haskell program compiled to Webassembly (WASM) with mainline ghc and using the browser DOM. ghc's WASM backend is solid, but it only provides very low-level FFI bindings when used in the browser. Ints and pointers to WASM memory. (See here for details and for instructions on getting the ghc WASM toolchain I used.) I imagine that in the future, WASM code will interface with the DOM by using a WASI "world" that defines a complete API (and browsers won't include Javascript engines anymore). But currently, WASM can't do anything in a browser without calling back to Javascript. For this project, I needed 63 lines of (reusable) javascript (here). Plus another 18 to bootstrap running the WASM program (here). (Also browser_wasi_shim) But let's start with the Haskell code. A simple program to pop up an alert in the browser looks like this:
-# LANGUAGE OverloadedStrings #-
import Wasmjsbridge
foreign export ccall hello :: IO ()
hello :: IO ()
hello = do
alert <- get_js_object_method "window" "alert"
call_js_function_ByteString_Void alert "hello, world!"
foreign import ccall unsafe "call_js_function_string_void"
_call_js_function_string_void :: Int -> CString -> Int -> IO ()
call_js_function_ByteString_Void :: JSFunction -> B.ByteString -> IO ()
call_js_function_ByteString_Void (JSFunction n) b =
BU.unsafeUseAsCStringLen b $ \(buf, len) ->
_call_js_function_string_void n buf len
void _call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len) __attribute__((
__import_module__("wasmjsbridge"),
__import_name__("call_js_function_string_void")
));
void call_js_function_string_void(uint32_t fn, uint8_t *buf, uint32_t len)
_call_js_function_string_void(fn, buf, len);
call_js_function_string_void(n, b, sz)
const fn = globalThis.wasmjsbridge_functionmap.get(n);
const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
fn(decoder.decode(new Uint8Array(buffer, b, sz)));
,
document.alert. Why not
pass a ByteString with that through the FFI? Well, you could. But then
it would have to eval it. That would make running WASM in the browser be
evaling Javascript every time it calls a function. That does not seem like a
good idea if the goal is speed. GHC's
javascript backend
does use Javascript FFI snippets like that, but there they get pasted into the generated
Javascript hairball, so no eval is needed.
So my code has things like get_js_object_method that look up things like
Javascript functions and generate identifiers. It also has this:
call_js_function_ByteString_Object :: JSFunction -> B.ByteString -> IO JSObject
document.getElementById
that return a javascript object:
getElementById <- get_js_object_method (JSObjectName "document") "getElementById"
canvas <- call_js_function_ByteString_Object getElementById "myCanvas"
get_js_object_method. It generates a
Javascript function that will be used to call the desired method of the object,
and allocates an identifier for it, and returns that to the caller.
get_js_objectname_method(ob, osz, nb, nsz)
const buffer = globalThis.wasmjsbridge_exports.memory.buffer;
const objname = decoder.decode(new Uint8Array(buffer, ob, osz));
const funcname = decoder.decode(new Uint8Array(buffer, nb, nsz));
const func = function (...args) return globalThis[objname][funcname](...args) ;
const n = globalThis.wasmjsbridge_counter + 1;
globalThis.wasmjsbridge_counter = n;
globalThis.wasmjsbridge_functionmap.set(n, func);
return n;
,
This blog post was sponsored by unqueued on Patreon.
If this were twitter (and if I had a twitter account, which I don't),
this post would start with "RT". As it is, you'll have to make do with
