At some point this year I realized I’d almost entirely given up on ever finishing BOOL, and I decided that was okay. The language was always butt ugly, and conflicting design goals combined with a lot of indecision,… it just began to seem pointless, so I decided to stop thinking about it and move on.
But recently I find myself noodling around with the idea of, yes, damn it, finishing it in some form, even if it doesn’t come that close to the original dream (which has proved problematic).
I’d gotten pretty close back in 2016 with Python, so why not?
The biggest issue has been how data is handled.
The problem is that, per a key design goal, BOOL “object” code (which is literally a tree of objects) has very nearly a one-to-one correspondence with the source code. Which means data declarations are objects in the code tree.
But the code tree cannot be modified at run-time, so the actual data bits have to be stored somewhere else. Further, the code tree can, of course, be re-entered by a thread, so multiple locations for data bits are required.
Most systems use the stack for local variables, which solves this problem nicely (except for some hacking holes it creates).
BOOL’s architecture is very different and doesn’t lend itself to this technique. The original design uses a software “parameter stack” for passing and returning objects, but not for local variables.
Data instances end up having three levels:
Firstly, the declaration object that specifies the object’s name, declared Model, and (optionally) an initial value. This becomes an object in the code tree. At compile time, it’s assigned an index (of variables in the current Action).
Secondly, at run-time, when an Action is invoked, there is a Call Frame (CF) associated with the call. The declaration indexes all reference slots in the CF. These slots contain the object’s actual Model and a Data Key (DKey).
Thirdly, each Model maintains a data pool for its instances. The actual bits can only be accessed via Model methods (using the DKey).
Which is a bit of a complicated mess, but I haven’t been able to find another way to do this that aligns with BOOL design goals and provides the necessary capabilities.
For one thing, keeping track of which objects still need their data bits ends up requiring reference counting, which is fine, but it’s not something I’ve ever had to implement, so writing code to pull it off is off-putting.
(I spend months trying to figure out a way BOOL could know for sure when a variable goes out of scope, but I found so many exceptional situations that I think it may be impossible.)
((What I may do, just for now, is let each data instance live forever and just eat a lot of memory. BOOL was always a “demo” language, so that’s not a huge restriction.))
In any event, after not thinking about BOOL at all for a very long time, maybe coming back fresh will lead to further real progress.
Or at least some version of it I can call done.
I do have the macro compiler and a rough RTE, so I really am close.
My biggest problem right now might be my constant indecision about certain syntax details. Hard to write a compiler when you keep changing your mind about the syntax!
So stay tuned!