Tag Archives: BOOL O/S

BOOL Message Center

It’s been a while since I’ve waded in BOOL waters. As always, there are periods of strong interest and periods — often quite long — of dormancy. Finally solving most of the implementation problems of the language triggered a period of disinterest. That and some uncertainties about exactly how to implement Action Methods, especially the “new” method.

But I recently did have some fun with a BOOL/OS subsystem, the Message Center Service. I roughed out a crude working version in Python that provides a flavor of the real thing’s architecture.

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 →


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 →