One of the more unusual aspects of BOOL is its List notation, which is somewhat similar to how Python uses indentation for code blocks. (In fact, the List Character can be defined as the TAB character, which makes BOOL look very similar.)
This post discusses current (and presumed final)
List syntax, including
But hopefully once and for all. What started in Disarray, and then seemed briefly Final, yet was still Revisited, has, just perhaps, at last settled into a design that doesn’t nag me. (Or, at least, doesn’t nag me so much I find myself constantly chewing on the bone.)
It feels that I have finally solved how I want BOOL to do arrays!
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?
When BOOL gets into trouble at run-time it throws an Exception. Such problems include resource issues (like a missing file) or code issues (such as when a Model can’t find an Action to handle a received Message).
There are a some native Exceptions, but user code often extends those for the sake of the application (following a common model used in Java, Python, and many other languages).
Picking up the topic of Model implementation two years later, some further thoughts about the new method as well as about the set and get methods.
The summary here is that all three are virtual methods built into the implementation. They have to be to handle the under-the-hood aspects of Instances. They can be “extended” by user code, but not over-ridden.
Strange how my thoughts turn to BOOL in the early part of even-numbered years. (I wonder if it has something to do with the San Francisco Giants baseball team, although I don’t know why, and I’ve been hitting even-numbered BOOL version years longer than they’ve been winning World Series, plus I hope they don’t win this year.)
But in any event, I found myself pondering the
*array type (again)…
It’s been a while since I’ve waded in BOOL waters. As always, there are periods of strong interest and periods — often quite long — of dormancy. Finally solving most of the implementation problems of the language triggered a period of disinterest. That and some uncertainties about exactly how to implement Action Methods, especially the “new” method.
But I recently did have some fun with a
BOOL/OS subsystem, the Message Center Service. I roughed out a crude working version in Python that provides a flavor of the real thing’s architecture.
One of the last hurdles involves the implementation of the new behavior. Models manage Instance value objects and provide new data objects (used by Instance objects to populate Call Frame slots). Model objects must provide an API to support creating and destroying Instance objects as well as manipulating their value objects.
There is a design choice involved with regard to how Instance objects are bound to their Model object. A similar choice exists concerning Actor objects and their Action objects. (Actors can be called “instances” of an Action.)
The choice is between a BOOL-like design where the Instance sends a message to the Model, or an implementation design that lets the Instance directly call the Model. This post documents the two choices and the resolution to use the latter.