16 ms·
Show HN: Common Lisp running natively over WebAssembly for the first time
A month or so ago, I ported a Common Lisp implementation (npt) to WebAssembly to make a silly blog post, because I was bored and have a lot of time on my hands to waste with things like this (I don't have a job, and because I have next to no experience, these meaningless, silly projects tend to fill what time I do have).
This is significant as it's the first time Common Lisp in particular has ever been hosted on it; wasm has a few poor decisions in its design that make it less-than-conducive to being a target for Common Lisp, and a lot of the more interesting implementations require an implementation to already be on the platform for bootstrapping purposes.
My previous attempts using other implementations haven't gone so well, despite throwing a lot of time at it (as an example, I have a fork of Eclipse Common Lisp, a defunct implementation from the 1990s, sitting on my disk with a few hundred lines of changes that I finally got to successfully compile and run a handful of very basic expressions, but it blows up when you try and define anything). In comparison, I was pleasantly surprised by how little I had to do, even though I did end up scrapping loads of lines of my own changes to npt in the process as I got a handle on how to make it work acceptably.
The Emscripten toolchain and I don't get along, partially because I don't like inlining ECMAScript into my C and vice-versa, so it's little more than a neat little demo right now.
You can load slightly more complex programs into it by hijacking the "imp" ECMAScript function every few hundred milliseconds with strings containing complete forms (this is essentially a batch processor, so there's no interactivity that allows it to wait while you decide what the rest of a form should be). Only one at a time, though. It's not that fancy.
If you mess up at all, even just a little error, it will crash. This is by design; I disabled the debugger. It's a giant hack, and the hack I eventually decided on left it impossible to have a debugging experience, with the benefit of getting to use a closer-to-unmodified npt.
This could be more useful, if I spent more time on it, but it's more fun if it's just a demo. I hope you enjoy the toy I made for you.
https://en.wikipedia.org/wiki/Batch_processing https://en.wikipedia.org/wiki/Batch_processing
If you don't know what forms are in the context of Common Lisp:
http://www.lispworks.com/documentation/HyperSpec/Body/03_aba.htm http://www.lispworks.com/documentation/HyperSpec/Body/03_aba...
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_c.htm#compound_form http://www.lispworks.com/documentation/HyperSpec/Body/26_glo...
- deleted 4y ago[deleted]
- kotborealis 4y agoGreat work! A small nitpick — the page is a bit hard to read, links have low contrast, you can check it using accessibility tools.
- rsstack 4y agoI initially rolled my eyes that it's yet another pointless text contrast complaint - and then I opened the site. My eye sight is great and that contrast (and border) is not great :)
- deleted 4y ago[deleted]
- Existenceblinks 4y agoI hope someone would create a tutorial which is using a toy programming language to compile to webassembly from scratch. Using existing language is too opaque to understand anything.
- deleted 4y ago[deleted]
- metagame 4y agoThat sounds like a good idea. Have you considered writing it?
- Existenceblinks 4y agoI was trying to compile my internal data and encounter "what's the right way to represent string in Webassembly" so that's why I came up with the demand for tutorial from a toy language because it has less features to worry about. I don't understand why I got downvoted, it seems HN users with power to downvote just see everything is a nail they wanted to exercise their power. Anyway, I'd probably write one when I actually implement it. I know linear memory is available but not sure whether or not having GC or mechanism that make memory safe.