Category Archives: Basics

Singleton Messages and Actions

A recommended idiom involves defining Actions to implement Singleton Messages. This cleans up source code by removing the need to use the semi-colon, and shifts possible “Unknown Message” errors to data type errors, some of which can be detected at compile time.

Continue reading →

Casting Values

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.

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 →

List Syntax

A design goal BOOL had from the beginning is that it should not use block scope delimiters. That is, I wanted neither the C family’s {curly braces}, nor did I want the ALGOL family’s BEGIN and END keywords. But how to indicate scope? If tokens at the ends are forbidden, the items themselves must somehow indicate their scope.

I hadn’t yet heard of Python and its elegant use of whitespace, but that’s the sort of thing I wanted. I came up with something similar, called “dot lists.” (Just not trusting the idea of indentation alone — turns out it’s totally bitchin’!) As it happens, since you can re-define the “dot” character, by changing it to a TAB character, you can have Python’s whitespace indentation!

With a couple extra BOOL-ish wrinkles!!

Continue reading →

Packages & Modules

The smallest functional unit of BOOL is the Module. A module contains code and local data (Actors and Models and Model instances) along with information that identifies it to the system. A BOOL Module is an active object with a meta-class.

Actual applications are made from one or—almost always—more modules. A BOOL Package is also an active object. Its meta-class is related to the Module meta-class.

Packages have several distinct types:

Continue reading →

Symbol Crazy

By now you’ve noticed that BOOL uses a lot of symbols. It steals (and runs with) the ball from Perl mostly, which uses punctuation symbols to determine basic data types (scalar, array, hash, and so forth). Many forms of BASIC have also used punctuation symbols to determine data type.

BOOL uses them to define basic meta-types of objects in BOOL, and it uses them to distinguish between definitions of new objects and references to existing objects.

And while it does make BOOL have a bit of that “line noise” look that so uglifies Perl, the syntax has been there from the very beginning, so it’s not going anywhere. Consider it part of BOOL’s “charm”.

Continue reading →

Here’s A Point

For a long time the “Hello, World!” program was the first app a programmer tried with a new language or situation. It’s a quick way to test the general operation of things.

When it comes to object-oriented languages, an object-oriented first program needs a simple object. I’ve long thought that the “XY Point” made an outstanding “Hello, World!” object. It’s basically very simple, so it’s easy to do. And you can extend on it nicely once you get your Point working. You can extend a 2D Point to a 3D Point, or use Points to create Shapes.

This article is about how you create a Point Model in BOOL.

Continue reading →

Speaking of Names

In the last article I explained where the name, BOOL, comes from. This article concerns the names of things within BOOL.

Languages have various terms for the concepts reified by by the language. For example: “sub-routine”, “function”, “method” and “procedure” all describe the same thing, a chunk of code that can be called by other code. The terminology for data objects is even more diverse!

In part to find the most descriptive words—but also to find new terminology for fun—BOOL has its own terms for the basic concepts.

Continue reading →

What’s in a Name?

BOOL is a language of a fevered imagination—the result of years of tinkering, infrequent bursts of activity and long dry spells. BOOL is at least 20 years in the making, and it has been through many versions and variations. It’s like a model train project I’ve been working on in my spare time for many years!

It was never intended as a serious language, so developing the spec and the supporting software (for what is a language spec without at least one compiler?) has never been a serious project. Still, this one never went away, and getting it into the light of day after all this time seems only right and just.

The name, BOOL, has four references:

Continue reading →