Tag Archives: BOOL RTE

Binding Instances and Models

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.

Continue reading →

Advertisements

Action Walkthrough, part 1

This post series explores an Action in detail with emphasis on the Instance objects, especially the dynamic (temporary) ones. Posts are broken up mainly for size considerations.

Continue reading →

Temporary Objects

One of the final hurdles in designing a BOOL implementation involves temporary objects. Any operation on an object may result in a transitory new object that is consumed by later operations. For example, in the arithmetic expression “5 x (3 + 4)” the addition operation creates a transitory value — 7 — required by the multiply operation.

The question for an implementation is, “Where to store such temporary objects?” In some languages, CPU registers suffice to store transient values (such as seven), but in object-oriented languages, registers aren’t enough. Objects take up some space, and often temporary objects need to be addressable.

Continue reading →

It’s Alive! (Sort of)

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.

Continue reading →

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).

Continue reading →

Native Objects, part 1

Languages generally come with two distinct sets of features: native objects and library objects. The former are often built into a language, for example int and float in the C-family languages, or date and array in JavaScript. Such “binary” native types are quite distinct from user-defined types. In other languages, Python for example, there is little or no distinction between native types and user-defined types.

The lack of distinction is more common in object-oriented languages, and BOOL is not exception. Native types “look” identical to user-defined types; operationally they are identical. The next few posts discuss BOOL’s native objects.

Continue reading →

BOOL RTE (continued)

Picking up where I left off regarding run-time sub-systems, there are a few more to mention. In a stripped-down version of BOOL, these sub-systems could be stubbed out, but proxy agents would still have to represent them. All the sub-systems discussed in these two articles are required to be present, but not all are required to be functional.

Obviously, non-functional sub-systems still accept Messages and respond appropriately, if only to signal their lack 0f function. No application can fail due to lack of a sub-system’s presence, but any application may be unable to continue due to lack of a specific resource.

This means applications must be aware of the potential for a sub-system to return a “no can do” response.

Continue reading →

BOOL RTE

The architecture of the BOOL RTE (Run Time Environment, also  Run Time Engine depending on context) reflects the fundamental nature of BOOL. In particular, that refers to BOOL’s message-passing nature and the use of a parameter stack for passing data.  (BOOL call frames use a mechanism not susceptible to stack frame hacks.)

Separate entities in the BOOL environment communicate via message-passing, just as BOOL program objects do (and to a large extent, just as BOOL operates internally). As such, messaging is a native feature of the RTE and is supported in two basic forms.

Essentially, the BOOL RTE is like an operating system. It provides a set of standard systems available to running BOOL programs. The intent is that, as with Java and other platform-agnostic languages, BOOL programs are highly transportable to any platform with a BOOL RTE.

Continue reading →