There was meant to be a third article in the Native Objects series that would discuss the Actions (“methods”) supported by the native Models (“classes”). But I’ve only begun to define those things. For now, suffice to say that typical data types (integers, floats, strings, etc.) have the methods you’d expect. Assignment for all, basic math for the numeric types, stringy stuff for the string; you get the idea.
I’ve reached another major milestone, but I’m also about to begin another design phase as I figure out exactly how to implement the native Models. And I may be taking a break from this blog to give BOOL a rest and to deal more with other matters.
Picking up from the previous post, I want to get into the Python binding for Actions in more detail. I’ve got several examples to help demonstrate various aspects of what the parts of the Action object mean. The design appears solid enough to make it official and move on to the next stage.
Speaking of which: huge milestone in the last few days! The bottom line is that, for the first time, I can generate BOOL objects from a higher-level language. Essentially, I wrote a kind of “macro-assembler” that reads a fairly simplistic language and emits (Python) BOOL objects. It’s a major step in bootstrapping the run-time environment objects necessary as well as providing examples for working on the run-time engine!
It rates its own article soon. For now, Actions ala Python:
BOOL has an
#inline option for Action definitions that allows (but does not require) treating an Action as if it was inserted into the code flow. There is also the idea of native Actions, defined as such by the standard, which are also allowed to be inline.
But a design goal is the ability to implement basic language constructs (such as
if statements and
while loops) in the language itself.
So here are some of those native Actions:
The last topic to cover in this series concerns Action parameters. There are several basic categories of Action parameter; which one is most appropriate depends on how the Action is used. In turn, the category used may have consequences on how the Action is invoked.
The strictest category forces parameters to a specific Model. At the other extreme, the generic category allows any type of parameter. Intermediate categories restrict inputs to a class of types.
At its heart, BOOL has a fundamental principle: Everything is an object. This includes some non-obvious things, such as definitions and even individual statements. In particular for this discussion: statements. For example, in BOOL, an if-else statement is a distinct object.
All statements in BOOL are references to some Action object, which is invoked via an Actor object (Actors perform Actions). In a BOOL program, there can be many Actors that perform a given Action. For example, each occurrence of an if-else statement in the code is an Actor object that invokes the if-else Action.
Picking up where I left off, after some consideration, I’ve decided to require Instance definitions on both inputs and outputs. This makes them symmetrical, for one thing, and that seems more sensible. It also helps with the issue of migrating a new Object Instance up a chain of Actor calls. As icing on the oatmeal cookie, it also insures a type signature on the return object(s).
I’m still wanting to allow multiple return objects for Generic Actions (just for the sheer weirdness of it), but if it gets too nightmarish, it can be tabled for deeper consideration.
I’ve been working on Actions recently, and have maybe finalized a few things that should allow me to move forward on an implementation design. It’s become very clear that Actions are central to that design.
In addition to their role as BOOL “sub-routines” and Model “methods” they also implement language flow control (via
@while and others). As such they end up being part of the design for most other areas of BOOL.
Given that Actions have been one of the more poorly defined areas of the language, it’s high time to figure out exactly how Actions behave!