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.

There is the situation when an operation takes multiple operands, and one (or more) of those operands are inappropriate for the operation. For example, suppose an integer add operation was passed an integer object and an open file object? There is generally no “add” semantic for an integer and a file.

Total incompatibility results in a run-time error, but sometimes values are compatible enough for the operation to proceed. How the system accomplishes that often involves casting one value into another.

One language question designers need to address is whether objects are passed by value or by reference when invoking callable objects. It’s common in object-oriented languages to pass by reference to avoid having to build copies of passed objects.

BOOL uses pass by reference, which begs two questions: Do we provide a means to pass by value when desired? And if so, which side — caller or callee — can do the magic?

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.

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

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.

I’ve reached a huge milestone with BOOL, and it all happened through serendipity! I was creating canonical source examples and hand-compiling them into an off-the-cuff “language” to give me some sense of what the compiler would have to do to generate output. It’s probably the robot in me; when I invent off-the-cuff pseudo-languages to express an idea, I tend to make them very regular, very machine-readable.

This time that got me to thinking, “I bet it would be fairly easy to write a compiler for this stuff!” The figuring out part (the hard part) of the parsing is already done; the code I was generating (as a human compiler) just needed to be assembled.

I think the final piece of the array puzzle finally fell into place. The issue resolved when I last wrote about arrays — whether all data Models have array capability versus arrays being a distinct data model — still stands.

The final piece involves a slight syntax change and — much more importantly — the full rationale for the array syntax. Not really having one was a bother; it made arrays seem arbitrary and patched on. The rationale brings them more fully into the BOOL fold.