I can't believe it's already been half a year since my previous log entry, but I guess it's now September. I had planned to work on several of my projects a lot over the summer, and while I did get some work done on a fair few of them (and start some more along the way), I ultimately spent more time relaxing and doing "nothing" than I had planned. (At least it was a semi-constructive and entertaining sort of nothing).
After the long and much-needed break, however, I am back! I'm still pretty busy, but I'm currently working on an overhaul of the entirety of the code underlying my Lisp-like language. After thinking long and hard about how best to implement something like Scheme's call-with-current-continuation, I decided that the implementation of the language would be easiest to accomplished and have the best clarity if I redid the whole thing to be based off of a virtual machine. In this way, I would be forced to maintain explicit call and data stacks, and I had been reading some tutorials on implementing simple stack-based bytecode virtual machines which seemed pretty simple.
Currently, I'm working on implementing the different data types I need (i.e. functions, integers, etc.) while also planning out on paper what the macro system will look like, becuse what's a Lisp without macros? So far, I think I've figured out how to deal with functions creating and returning other functions, i.e. something like:
(lambda (x) (lambda (y) (+ x y)))
In this case, the inner lambda would get expanded into a function object with code containing references to the x and y symbols; the outer lambda would generate a function that returns the inner as a closure, while also adding its arguments to the symbol table associated with its stack frame (which would be pointed to by the table for the closure generated to wrap the inner function). Yeah, kinda confusing stuff. Basicaly, the macro processor will recognize that the outer function is returning a closure and add its arguments into a symbol table instead of indexing them out of a list.
I'll try to add another log entry with actual code for what all this would look like as soon as I have some.