Environment

Module

A BOOL Module is the basic runnable unit in BOOL. A Module is an application or program (although a Module can also be a library or resource). All the BOOL code (constants, library functions, native objects and the application) necessary for the program to run is in the Module.

Modules are BOOL meta-types and have a defined structure. A chief part of a Module is its NameTable, which is a dictionary of what the Module (publicly) contains.

A Module (unless it’s purely a resource) also contains at least one callable Action listed as the default. It is this Action that BOOL invokes to “run” the Module.

The standard program Module includes three Actions:

@system, which calls

@global, which calls

@main

A very small program might be contained entirely in the @main Action, but usually more are involved. Such Actions (including @main) are defined within the @global Action’s namespace.

The @system Action contains native objects and constants. The @global Action contains any objects the user imports or defines at the top level (and actually, @main is just one of those).

Call Frame

At run-time, there is a call frame (CF) associated with each Action BOOL invokes. The CF acts like a stack frame in holding input and output parameters as well as local variables.

When an Action is invoked, it creates a new CF. This frame links back to the frame of the calling party. There is a chain of call frames linking back to the first Action invoked. When the environment looks for an object, it starts with the current CF and as far back as necessary to find the matching frame.

A BOOL Address is a tuple consisting of a name and an offset. The name is the name of a call frame (actually the name of the Action holding the call frame).

Something to keep in mind: BOOL allows looking back the call chain for an address, but in the case of recursion returns the first (most recent) frame that matches. There is (currently) no way to reach back past the most recent recursion.

Something else to consider: If one is deep in recursion, accessing global and constant objects does mean traveling all the way back to the @system or @global Actions. An implementation might consider a “short-circuit” path to handle references to objects in those spaces.

Environment

The Environment is the Run-Time Engine. It is not a BOOL object or meta-type. It contains the machinery a BOOL program needs to run.

The BOOL Environment has a list of instances of the meta-types that comprise the functional units of BOOL. These meta-objects implement the basic behaviors of those units. Their API consists mainly of the HandleMessage() method, which takes the address of a BOOL object (necessarily of the instance’s type) and a message for that object.

Certain specific meta-objects extend the API to include an access method for their “child” objects. For example, the Model meta-object handles messages received by the Instance meta-object’s clients, so it exposes a dispatch() method. On the other hand, the Model meta-object almost entirely ignores received messages.

The Environment also contains the PStack (Parameter Stack). The “stack” passes addresses and newly created data objects between operations mainly in response to messages (I’m tempted to write “solely in response”).

The stack can also contain the special BOOL Address object, which is a tuple where the first item is ADDR and the second is a BOOL Address. This distinguishes the object from a data object (where the first item is OBJ).

The API is sparse:

SendMessage (address, message)

GetObject (addresss)

PStack.push (item)

PStack.pop ()

The first, SendMessage(), is the primary API into BOOL. It takes the address of some BOOL object and a message for that object. Under the hood, it looks at the passed object (via its address) and uses its meta-type (first datum in the object) to select the meta-object that handles this object. It hands off to that object’s HandleMessage() method, passing it the address and message.

The last two methods access the PStack. These methods transfer data and address objects between the stack and the current Call Frame.

The complete environment looks like this:

Workspace

The BOOL Workspace extends the Environment to include:

Modules (O/S and applications)

Multiple Address Space Slots (for multiple Modules)

Ports (for Inter-Process Communication)

I/O (adapters to connect to outside world)

The idea is to create a BOOL O/S that runs BOOL applications.

The Workspace is only a design idea at this time. An even more distant idea allows different Workspaces to interconnect to form a single BOOLSPACE. (Eventual global domination is the actual secret goal of BOOL.)