Ok, so I’m now a few months into building a custom (almost from scratch) #Lua implementation for @silverbulletmd dubbed #SpaceLua (for reasons).

A few things that panned out really well, and a few surprises that I did not anticipate:

0. General recommendation: don’t do this. Don’t just implement a full programming language because you think it’s a good idea. I also told this myself. It didn’t work. It was a “I’ve don’t this stuff before, I can do it again” type of deal. I was mostly right. But don’t do this.

1. Initially I opted for a custom interpreter (implemented in TypeScript) because I wanted to expose asynchronous (promise based) JS APIs to Lua, and I didn’t see how to do that nicely with a #Wasm-compiled version of the official Lua interpreter. Also I felt that having full control of the running system would turn out to be valuable down the line (I was right on this one).

2. I got the parser part mostly free. I found an existing Lua grammar for the Lezer parser library that #SilverBullet uses. Had to add a few things and had some struggles. This part was pretty seamless with a few glitches here and there.

3. Implementing the core interpreter runtime was actually quite easy. Lua is a mostly simple and small language. Again, I’ve done this before so that helped. Writing good test suites makes this doable and AI helped a lot generating those test suites (because it knows Lua).

4. What I didn’t anticipate is the pain in implementing the full Lua API, especially the `string.*` one which has its own pattern matching language (similar but distinct from regular expressions), which honestly I could do without. But it’s there, and people want to use it, so I need a full implementation. Issues keep coming up, though.