Great work! A small nitpick — the page is a bit hard to read, links have low contrast, you can check it using accessibility tools.
[deleted]
Show HN: Common Lisp running natively over WebAssembly for the first time
31–40 of 72 posts
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#32I 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]
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#33Like reading Rfc in 1990s … a bit odd choice to use this format and font to sell anything these days.
[deleted]
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#34...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…
So true! Also, there are no decent UI frameworks for Lisp, so it's impossible to build a full stack app that looks good in a modern browser without adding a TS or JS web component layer. And... There's no modern IDE for Lisp. I think this aspect of ignoring UIs and aesthetics has seriously held back CL.
[deleted]
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#35...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…
The hyperspec is copyrighted and licensed in a way where we can't change it at all. It's like the primary source to learn so impossible for anyone knowledgeable to clean-room reverse engineer a new one.
...you're not joking, right? jeeezus
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#36...god, my eyes ...why is everything CL plagued by such horrible design choices (hyperspec, Lisp-IDEs... all!) - why such ugly colors, ugly typography, bad contrasts, ugly logos, ugly diagrams, ugly supporting graphics?! I know that even the language itself is kind of the opposite of "beautiful", but the way all docs, blogs, websites etc. look ...seriously, is this intended to scare away any aesthetically sensitive p…
The hyperspec is copyrighted and licensed in a way where we can't change it at all. It's like the primary source to learn so impossible for anyone knowledgeable to clean-room reverse engineer a new one.
At least in my country you'd be perfectly within your rights to distribute a program that would modify it automatically for every reader who'd want to read a modified version, since as per our copyright act, you're entitled to do pretty much any modifications to the copyrighted works that you possess, as long as you don't redistribute them.
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#37Great work! You write, > …wasm has a few poor decisions in its design that make it less-than-conducive to being a target for Common Lisp… Could you say a bit more about those design decisions?
Not OP, but as a fellow Lisp-on-wasm developer one problem is that the current release doesn't support tail call elimination. There's a proposal for it (a tail_call instruction), and Chrome has implemented it, but the Firefox/Spidermonkey team hasn't prioritized it, so it's sat for a couple years. At least two implementations (maybe two browser implementations? I don't recall) are needed for standardization, so things remain.
You know, I wonder how seriously I could be taken if I duck-taped a wasm-capable browser together out of Servo and Wasmtime to make a second implementation and push it forwards...
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#38Great work! You write, > …wasm has a few poor decisions in its design that make it less-than-conducive to being a target for Common Lisp… Could you say a bit more about those design decisions?
Not OP, but as a fellow Lisp-on-wasm developer one problem is that the current release doesn't support tail call elimination. There's a proposal for it (a tail_call instruction), and Chrome has implemented it, but the Firefox/Spidermonkey team hasn't prioritized it, so it's sat for a couple years. At least two implementations (maybe two browser implementations? I don't recall) are needed for standardization, so thing…
There is no branch instruction at all?
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#39Earlier quoted context omitted.
I think a major limitation is that a WebAssembly module can’t run dynamically generated code, which is a huge part of typical Common Lisp implementations.
You could certainly generate a new Wasm module on the fly and then execute it from Javascript. Linking and sharing of memory should be possible. Pyodide can dynamically load libraries that are separate Wasm modules so it is worth checking out how that works.
IIRC inter-module calls are more expensive than intra-module calls though.
WASM also doesn't allow for functions with variadic return counts.
Re: Show HN: Common Lisp running natively over WebAssembly for the first time
#40Earlier quoted context omitted.
I think a major limitation is that a WebAssembly module can’t run dynamically generated code, which is a huge part of typical Common Lisp implementations.
"a WebAssembly module can’t run dynamically generated code" Why does it have that limitation, and is there any hope that it will someday be overcome?
On your computer, heap, stack, code, and global data all share the same address space. On the WASM virtual machine, only heap and global data share the same address space. Code and stack are abstracted away by the machine.
It was designed to support C-like languages, so you can do the equivalent of loading a DLL (or dynamic shared object). However in Lisp it is not unusual to compile just one function at a time. It's definitely possible to create a DLL for each function and load each DLL, but it requires a completely different architecture than most Lisp implementations use (in which, when you compile a function, it just writes the machine code to the heap).
There are similar impedance mismatches with so-called W^X systems (where you are disallowed from having a page be both (W)ritable and e(X)ecutable.