Tag Archives: BOOL Implementation

More about “new”

Picking up the topic of Model implementation two years later, some further thoughts about the new method as well as about the set and get methods.

The summary here is that all three are virtual methods built into the implementation. They have to be to handle the under-the-hood aspects of Instances. They can be “extended” by user code, but not over-ridden.

Continue reading →

Advertisements

Implementing “new”

One of the last hurdles involves the implementation of the new behavior. Models manage Instance value objects and provide new data objects (used by Instance objects to populate Call Frame slots). Model objects must provide an API to support creating and destroying Instance objects as well as manipulating their value objects.

Continue reading →

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 →

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 →

Pass by Value

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?

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-M

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.

Continue reading →

Python Actions

Picking up from the previous post, I want to get into the Python binding for Actions in more detail. I’ve got several examples to help demonstrate various aspects of what the parts of the Action object mean. The design appears solid enough to make it official and move on to the next stage.

Speaking of which: huge milestone in the last few days! The bottom line is that, for the first time, I can generate BOOL objects from a higher-level language. Essentially, I wrote a kind of “macro-assembler” that reads a fairly simplistic language and emits (Python) BOOL objects. It’s a major step in bootstrapping the run-time environment objects necessary as well as providing examples for working on the run-time engine!

It rates its own article soon. For now, Actions ala Python:

Continue reading →