I haven't been live-tooting #ICFP, mostly because I'm already live-{Discord,Slack,Notion,Telegram,Signal}'ing, and I can only multi-task so much while also trying to understand the talks …
but holy shit the Wasm talk by Andreas Rossberg1 was SO COOL
i had no idea what an interesting project, PL-wise, Wasm was; and I had no idea how #OCaml-y the whole thing has ended up being? like, it's an abstract stack machine and VM specification … but now it has functors(!!) and effects(!?)
when it's up on YouTube, definitely go watch it — I'll try to remember to come back and add a link to this thread …
abstracting 'up' from the hardware, instead of abstracting 'down' from some particular language (like previous efforts — JVM, CIL)
stack machine; implicit arguments; S-expressions; labels, branches to labels, functions with explicitly-typed arguments; and on top, everything comes in modules with explicit imports and exports
there was some time spent, that, uh, frankly borderline offended me, that i'm not gonna get into the details — but hey, they're very proud that the mathematical specification is "only two pages" (and very annoyed that they have to stoop so low as to provide a prose specification that is, god forbid, "two hundred" …)
some more slides on their '2 pages math, 200 pages prose' problem(ish), cool, but skipping over … not text-annotating these, feel like death, mildly don't care …
advertising an ‘explicit cost model’ — really important, maps well to things i understand about real-world industrial usage … (a huge upside of OCaml in production)
also quote: "the JIT can be pretty straightforward and dumb — can be very simple"
he talked about the optimization problem of balancing perf, generality (across both languages above, and architectures below), and simplicity; with the caveat that none of those could ever move away from the requirement of safety-and-portability
he talked about how one of the primary goals/constraints/jobs of the Wasm project is to keep the abstraction-level as low as possible (hence the title of the talk) — while still raising that abstraction-level when it's absolutely necessary, to provide the proper generality over architectures
examples he touched on:
number of registers is unknown, can't let the producer/compiler control that, have to depend on the VM/JIT
same for explicit function-addresses; not all architectures share data/code space, not all have function-pointers; have to have function-tables in Wasm instead
(another great quote: “the producer still needs to do the work of lowering their Rube-Goldberg-machine of a GC model down to this very simple model of memory-layout” 😅)
finally, and i didn't take a lot of screenshots here, because i was too gapey-mouthed :P — but WasmFX.
effects. in Wasm. holy crap.
(there were lots of PL-ey jokes of ‘they wanted stack swapping … which us PL'ers know, they really mean continuations … which us PL'ers know, they really-really-mean effect handlers …’)
he went into some detail about the challenges of implementing effectively-algebraic-effects in a low-level fashion, which has kinda never been done before, and breaks a lot of assumptions in the literature
(i said 'finally' i lied i am sick leave me alone okay ugh)
actually-finally, he touched on the module system, the missing pieces there, what all has been missing … and how after working hard to add and reconcile all the missing pieces to the existing modularization, they basically ended up with #OCaml-style functors … and then realized that … and then just decided to add #functors to #Wasm. 😱
(i had to duck out, so, again, no screenshots. cool as fuck, though.)
anyway, the last bit from my notes, is a bit more personal:
I’ve always been harping, for years, on how #OCaml and #JavaScript VMs are just such a surprisingly-fantastic, low-impedance match (see the whole #Melange, #BuckleScript, #ReScript, category — they're fantastic to use in practice); …
but now i’m learning that Wasm is … basically OCaml’s semantics, EVEN MORE DIRECTLY, in a bunch of cases, lmao.
Add comment