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!
I’ve changed my mind about the Gated List syntax. (These mind-changes are a key reason BOOL design is endless!) The idea of binding a label to the first statement in a List to indicate a Gated List just didn’t make good sense to me.
The problem is two-fold: Firstly, a key reason for Gated Lists in the first place is their use as named Action clauses. When the label is buried in the List (because it now belongs to the first List member), there’s no sensible way to migrate the label to the List. Secondly, a label on the gate expression really makes no sense and has no value.
So I’ve come up with something new!