Native Objects, part 2

The previous article introduced the basic run-time environment, the native @system and @global Actions that harbor all code and data objects. This article describes the required native Models and Actions found in the @system Action. There is a core set of Models required for BOOL to function and an extended set that provides more complex data types (such as trees and tables).

The BOOL RTE starts by calling the @system Action, which initializes all native objects (and constant objects). The Action’s last step is calling the @global Action, which initializes all library and user objects.

The @global Action’s final step is calling the user-defined @main Action, if the user has defined one.[1] If there is no such Action, @global just returns to @system, which returns to the BOOL RTE (which exits).[2]

By the time user code runs, native and library objects are initialized and available. The core set of objects is:

Native Models

The *null Model is one of several virtual BOOL Models (others are *any, *one). The value domain for the *null Model is only the Null object.
This is almost another virtual Model. It’s kind of a combination of the List meta-type and data Instance objects. It allows you to manipulate List objects somewhat like how the virtual *any Model allows access to any object.
Of course BOOL has a boolean Model! It’s value domain is the constants True and False objects.
One of two core numeric Models (see below); this one supports integer values. Currently that means Python long integers.
The other core numeric Model (see above); this one supports floating point values. (In this case, Python float values.)
This Model supports string values.
Arrays are a separate data Model in BOOL (rather than all Models having array capability).
JavaScript has a native date object; why not BOOL?

Native Actions

This Action exits the BOOL run-time engine. (The first three listed here are the only truly native Actions. That is, there’s no way they can have BOOL code implementations; they’re system-level.)
This Action forces an early exit from the enclosing Action. It has a “raw BOOL” syntax (@<) that is actually the “real thing.” The @return Action is just syntactical sugar (and the preferred usage).
@break and @next
These two apply to the enclosing List. The former forces termination of the List processing (executing or evaluating); the latter forces the List to restart. If the List is a loop, these function act as traditional break and continue do in other languages. Both have an underlying syntax: @_ and @^, respectively.The implementation of the @while and @until loops below insures the loop condition is evaluated on a @next Action.
@if [@elif] [@else]
This important Action implements the if-else code flow control structure. Selection can be accomplished using Gated Lists (which is what this Action does), but the native Action (which can be implemented inline) makes the code more expressive.
@while and @until
Mirror images of each other, these Actions implement the basic do-while and do-until loops. Both feature top-of-the-loop expression evaluation (so if the expression never evaluates True, the loop code never executes).
This Action implements a standard “for” loop with an index variable. The Action takes an index object, a range object and a list (or single object) to iterate over.
The version of a “for” loop implements iteration of a list of objects from some container. The Action takes an object holder variable, a container or list object and target to iterate over.
@switch [@case] [@else]
A more complex kind of selection Action, it functions just like any switch statement. Each case is compared to the switch expression until a match is found. If none is, the Action does the else case.
@do...@while and @do...@until
Mirror images of each other, these Actions parallel the while and until loops above. In this case, both feature bottom-of-the-loop expression evaluation (so the loop code always executes at least once). However! Allowing these requires allowing extended Action signature matching at run-time. Currently only the first word of an Action is its key. In this case it results in two Actions named do!

Native Constants

Can be used to mean “no value” it has the same function as NULL in C or None in Python.
False and True
The boolean constants mentioned above. The true: and false: Messages return these values, although BOOL objects can have intrinsic “truthiness” allowing them to be used in expressions expecting a True/False value.
0, 1, 42
Integer constants pre-defined in the environment. Other constants are added as required and become native objects.
Pi, E, C
Special tokens recognized as the mathematical values for pi, e and c (speed of light).

(Yes, some of these do reflect my personal interests. Why do you ask?)

[1] Presumably the user does define @main so that the module has a chance to do something useful. (It’s not impossible that all the code might be in the initialization List of some global Instance object. Actions have a similar aspect in that, for very simple Actions, the code can be entirely in the initialization List of the return object(s). [Yes, I’m still dithering about Actions returning multiple objects.])

[2] There is also a difference between the RTE running a module (by ultimately invoking @main) and the RTE loading a module. The BOOL O/S has the capability of loading library modules that provide software services needed by running application.

%d bloggers like this: