This project started with me going through "Writing An Interpreter In Go" (https://interpreterbook.com) and "Writing A Compiler In Go" (https://compilerbook.com) books by Thorsten Ball (however I've decided to implement it in C instead). Later I've decided to continue working on it with the ultimate goal of making an easy to use library out of it - something you can place in your source tree and immediately start tinkering with. I've also expanded upon the Monkey language (https://monkeylang.org) by making it more mutable and adding additional constructs such as loops and modules. A lot of time was spent on making it faster by not allocating memory where possible so it should be reasonably fast (pointers are kept in IEEE double NaN payloads so there's no need for allocating memory when doing numeric computations). It's still work in progress and I expect there to be plenty of undiscovered bugs but it should be quite useful already if you need a drop-in scripting language in your application. The language itself is also quite easy to use with it's C-like syntax and useful error messages.
I could be wrong about him having based his language off that book, but when he mentioned writing it first in Go I got the vibe it might be, plus he recreated Monkey in V. It amazes me how much V has grown in a short period of time, and how much your language has grown as well.
I've been wanting to buy those two books for a while, and I think I'm just going to have to based on the results. This reminds me of the CoffeeScript developer who also read a similar book years back and built CoffeeScript:
I can definitely second the recommendation for those two books, they really opened my eyes to the basics of what is going on under the hood of a compiler.
Recently I've been trying to target Monkeylang to Webassembly which has been a fun, if albeit frustrating exercise :)
I think you're talking about "The SQLite Amalgamation" - https://www.sqlite.org/amalgamation.html. I hadn't heard of it before, so thanks for encouraging me to look it up - seems like it might come in handy!
I'm using a python script and a template to merge source files into ape.c so it's quite similar to sqlite's amalgamation. It's not as simple as joining a lot of files together though because there are dependencies between files and all global variables and functions need to be declared static.
In the example directory, it looks like you could compile a binary that takes a text file of ape code as a command line argument and interprets it. Sounds just like how something like python works. You could have this interpreter running on an embedded processor that could take in new ape code via serial or from a textfile on removable media or even from some sort of OTA update if you want to get fancy. It's much easier to have a small bootstrap/interpreter running on a chip that can load up new code than having to flash new firmware every time.
I'm not sure the terms are well defined, but here's my attempt. The BASIC implementation on a ZX Spectrum (and probably most 8-bit home computers of the 80's) was an interpreter but not a VM because it did not implement any isolation. A BASIC program could access any address on the machine and jump execution to any address. A VM, in contrast, would do bounds checking on pointer accesses and limit which syscalls were allowed. You'd expect that if two instances of a VM were run at the same time, that programs in those VMs would not be able to access each other's memory in general.
This project started with me going through "Writing An Interpreter In Go" (https://interpreterbook.com) and "Writing A Compiler In Go" (https://compilerbook.com) books by Thorsten Ball (however I've decided to implement it in C instead). Later I've decided to continue working on it with the ultimate goal of making an easy to use library out of it - something you can place in your source tree and immediately start tinkering with. I've also expanded upon the Monkey language (https://monkeylang.org) by making it more mutable and adding additional constructs such as loops and modules. A lot of time was spent on making it faster by not allocating memory where possible so it should be reasonably fast (pointers are kept in IEEE double NaN payloads so there's no need for allocating memory when doing numeric computations). It's still work in progress and I expect there to be plenty of undiscovered bugs but it should be quite useful already if you need a drop-in scripting language in your application. The language itself is also quite easy to use with it's C-like syntax and useful error messages.