BOOL or Bust

This is part five of a series celebrating the passing of BOOL, the “ship in a bottle” computer language I’ve been tinkering with for three decades. It’s a design dream, and I’ve decided to wake up.

Last time I talked about how BOOL handles data and why that was such an issue. This time I’ll ramble on about some of the other snarls that ultimately made things more complicated than I wanted. Simplicity and elegance were key design goals. I intended the run-time environment, especially, to be utterly straightforward.

Unfortunately, the behavioral design goals — the way BOOL should to act at run-time — ended up in direct conflict with that.

A great deal of that came from being stubborn about an early design goal: that core BOOL should be able to implement the rest of BOOL. Specifically, that BOOL needed to implement the @if-@elseif-@else construct in BOOL.

There is a similar problematic use case with the @switch-@case-@default construct. Let me explain…

§ §

One of the key characteristics that make a programming language a programming language is something that is formally called selection and commonly the conditional. It’s the ability, at run-time, to select among multiple paths through the code (depending on conditions at the time).

The simplest example is the IF statement:

IF x=0 THEN print "Zero!"

Which prints “Zero!” only if x equals zero; otherwise it skips it.

In some languages, the syntactical THEN is implicit and some form of punctuation or keyword structure tells the computer what the parts of the statement are:

IF (x=0) {
    print "Zero!";
    print "One!";
    print "Two!";

Such constructs also allow for multiple things to do in the IF block. (A lot of language syntax has to do with scope and especially block scope — lines of code that group together.)

There is the more verbose:

IF x=0
    print "Zero!"
    print "One!"
    print "Two!"

The important part is the basic construct:

IF <something-is-true> (THEN) <do stuff>

As it turns out, this simple version is all a programming language needs to qualify as having selection. All other (more sophisticated) forms of selection can be implemented with just the basic IF construct.

Conversely, every programming language must have some form of IF to qualify as a programming language. (HTML, for instance, doesn’t and isn’t. (This may have changed under HTML5; I haven’t looked into it, yet.))


As I showed you on the first day, core BOOL has an IF construct:

=? <expression>
.   <stuff-to-do-if-expression-is-true>
.   <more-stuff-to-do-if-true>
.   <even-more-stuff-to-do-if-true>

It’s all BOOL really has to have.

Which is exactly why it’s the only logical construct in core BOOL. In a sense, it’s a BOOL “atom.”

The construct is called a gated list. You may recall that, in BOOL, an equals sign explicitly begins a list. The question mark and expression make this a gated list.

BOOL has the core ability to define new Actions (procedures). This allows for the (usually as if) definition of standard BOOL logical constructs, such as @if:

>> *one expression
>> *any statements
<< *bool flag =t:expression;
=? flag
.  statements

That defines an Action, called @if, that acts just like an IF statement. It takes two parameters, a single object (*one) and any object or list (*any).

The body of the Action uses a gated list to do the actual work. Note that the Action returns the value of the expression (the t: (true) message evaluates its target and returns TRUE or FALSE).

So far it doesn’t seem like much of an improvement. All we’ve done is change the gated list example above to:

@if <expression>
.   <stuff-to-do-if-expression-is-true>
.   <etc>

Which does seem pretty much like a wash. (It does have a formal return value now. Gated lists don’t.) It’s a little cleaner and in line with general BOOL syntax, so it’s more elegant and expressive.

The value — and the problem — is in the extensions of the IF.


IF <something> THEN <something> is a simple construct, and most languages go at least one step further and allow an optional ELSE clause:

IF <expression>
  THEN <stuff-done-if-true>
ELSE <stuff-done-if-false>

This provides an alternate code path for when the test expression is false.

Many languages go one more step and add a repeatable, optional ELSE-IF clause:

IF <expression1>
  THEN <stuff-done-if-expression1-is-true>
ELSEIF <expression2>
  THEN <stuff-done-if-expression2-is-true>
ELSEIF <expression3>
  THEN <stuff-done-if-expression3-is-true>
ELSE <stuff-done-if-all-are-false>

And that’s where my troubles began.

§ §

One problem is that the ELSE clause is optional. So is the ELSE-IF clause, plus it adds the additional issue of being repeatable. How does one define an Action with optional and repeatable inputs?

Note that usually this is a syntactical issue handled by the compiler. The way BOOL maps source to run-time objects requires a function-based approach.

A tactic some languages use is function overloading, where it’s possible to have multiple functions with the same name, but which take different parameters. The computer figures out which function to invoke based on what the caller sends it.

I decided long ago not to use function overloading in BOOL. It requires too much of either the compiler or the run-time environment. So overloading was out. What I needed what a syntactical way to express optional and, especially, repeatable clauses.

Here’s my solution:

>>  *one if_expr
>>  *any if_list
@@elseif %optional %repeatable
>>  *one elif_expr
>>  *any elif_list
@else %optional
>>  *any else_list
<<  *bool swx = t:if_expr;
=?  swx
.   if_list
=?  not:swx;
.   set:swx t:elif_expr;
.   =?  swx
.   .   elif_list
=?  not:swx;
.   else_list

This obviously needs some explaining.


First, BOOL allows multiple clauses in an Action definition. Each clause is followed by one or more inputs for that clause. As discussed earlier, there can be only one return parameter; it follows the clause definitions.

Second, a multi-clause Action implies a section for each clause. Labels in square brackets identify clause sections in the body of the Action. Those sections bind with the input parameters for those clauses.

Third, if a clause is flagged as %optional inputs may not exist, in which case BOOL skips that clause section.

Fourth, importantly, if a clause is flagged as %repeatable then BOOL loops that section for each matching clause found (multiple @elseif clauses, for instance).

It allows the programmer to use many forms of the @if Action:

@if eq:x 0
.   print:"Hooray!"
.   print:"X is zero."

@if eq:x 0
.   print:"Hooray!"
.   print:"X is zero."
.   print:"Oops!"
.   print:"X is not zero."

@if eq:x 0
.   print:"X is zero."
@elseif eq:x 1
.   print:"X is one."
@elseif eq:x 2
.   print:"X is two."
.   print:"X isn't 0,1, or 2."

In each case, BOOL invokes the same @if Action. BOOL only does the sections of that Action that bind to clauses in the Actor. (The three examples above all compile to a single @if Actor linked to the @if Action.)

For the first example, BOOL only does the [if] section. The eq: expression binds to the if_expr object, and the list of print: statements binds to the if_list object.

For the second example, BOOL does the [if] and [else] sections. In this case the second list of print: statements binds to the else_list object.

For the third example, BOOL does all three sections, and it loops the [elseif] section twice, each time binding elif_expr and elif_list to different inputs. The first time it binds to the eq:x 1 expression and the second print: statement. The second time it binds to the eq:x 2 expression and the third print: statement.


At the beginning I mentioned the @switch-@case-@default construct. I won’t go into detail, but it’s another logical structure with optional sections (the last two) as well as repeatable sections (the @case clause).

Suffice to say that BOOL uses this way of writing Actions to define the @switch Action and some other intricate select constructs.

Syntactically and semantically, I was pretty happy with this. It creates a great deal of flexibility in how one defines Actions.

The problem was implementing it. That,… turned into something of a Rube Goldberg machine. Actions with repeating clauses required a complicated run-time approach.

There was also a tension between Model Actions and generic Actions, because of the way message passing works.

Model Actions pull parameters off the p-stack (parameter stack; a Forth borrowing). In contrast, generic Actions are invoked by Actor objects with links to the parameters. The bottom line is two different, not entirely compatible, approaches to using Actions.

By the time I got it all working, I wasn’t at all happy with the level of complexity. The vision of a simple elegant run-time based on a basic approach to objects… just wasn’t realistic.

Between the tripartite data implementation (and the need for GC) and the complications of the Action invoking mechanism, BOOL was proving to be much more of a challenge than I’d anticipated 30 years ago.

That said, the ability to define such complex function signatures is, as far as I know, “somewhat unique” to BOOL.

§ §

I could accept the challenge, but I wasn’t up for BOOL turning into such a complicated monster. A central point was simplicity and elegance.

The truth turned out to be that implementing the features and behaviors I wanted just wasn’t possible without creating a complicated mechanism. I could have lived with the data solution (kinda liked it, in fact), but I couldn’t live with the necessary intricacies of Actions (especially the disconnect between generic Actions and Model Actions).

That was the final straw.

It was a learning experience and an intellectual whetstone. I’ve applied some of my BOOL ideas in other more productive places, so at least it wasn’t all pure recreation.

And even if it all was just for fun, we all need time to play.

Stay boolean, my friends!

About Wyrd Smythe

The canonical fool on the hill watching the sunset and the rotation of the planet and thinking what he imagines are large thoughts. View all posts by Wyrd Smythe

26 responses to “BOOL or Bust

  • Wyrd Smythe

    As it turned out: Bust. (And not the good kind, either.)

  • Wyrd Smythe

    Thanks to those few silent mourners who apparently hung in there for the whole series. I appreciate the support!

  • SelfAwarePatterns

    Hey, at least it sounds like you learned a lot with the effort! That’s always a benefit.

    This reminds me a little of Andrew Tanenbaum’s old book, Operating Systems: Design and Implementation, which I once owned and perused, mostly as a curiosity. His OS, Minix, didn’t really go anywhere, but it inspired a guy named Linus Torvalds to take his own shot at it.

    (Tanenbaum himself eventually started one of the earliest electroral projection site, and still I think the best one.)

    • Wyrd Smythe

      Learned indeed, but mostly it was play and fun (except for the frustrations). I sure learned the difference between a design and its implementation! (I didn’t even get into the challenges the syntax presents the compiler. That was another place a cool design turned out to be an implementation monster.)

      ((It’s all a bit like how when an architect designs a cool curvy building. Builders hate those. Builders prefer building things with nice straight lines and right angles. If builders had their way, rockets would be square tubes with flat ends. 🙂 ))

      Operating Systems! That can be one of those “dark arts” sectors of programming. Torvalds is certainly one of the warlocks. The BOOL/OS is another area I didn’t get into. I actually like the architecture, although admittedly it’s not designed with speed in mind. (Altho I’m not sure it would be awful, either.)

      Like BOOL, it’s message-based. If an app wants to encrypt a document, for example, it sends a message to an encryption sub-system. That message provides access to the document. The sub-system sends back a message when its done. This way apps don’t have any access to library or OS code. All they can do is send messages and make requests.

      I think I’ll leave that for a someday (if ever) post on my programming blog, though. I only ever did one My Ideal System post, years ago, and it wasn’t anything to do with BOOL. (I still think it’s a sweet idea, though.)

  • Anonymole

    Torvalds is an amazing character. Git on its own is cause enough for celebration. Linux, on the other hand is more of a great-step-child of UNIX, BSD and MINIX. But, we all stand on the shoulders of giants don’t we.
    Creating an OS from zero? Way beyond me. A language and compiler might be fun though–if I was, like 30 years old. At 60 I’ve got maybe three neurons left that work.

    • Wyrd Smythe

      Heh, Torvalds is both amazing and a character! 🙂

      I passed 60 a number of years ago. This kind of stuff is how I try to keep my three neurons working so they don’t die! 😮

    • SoundEagle 🦅ೋღஜஇ

      Dear Wyrd, Mike and Anonymole,

      Hello! I can understand your sentiments, having been a programmer myself working through assembly language to 4GLs and OOPLs to create various standalone applications, websites and CMS themes amounting to thousands of pages of codes.

      Would I do it all again? No! I rather have the luxury of commanding the computer to materialize things and operations for me, as can be done in Star Trek.

      Happy July!

      May you have a wonderful weekend!

      Yours sincerely,

      PS: BOOL = Best Object Oriented Language 😉

      • Wyrd Smythe

        Ah, if only computers would do what we meant, not what we said. 😀

      • Anonymole

        I hate programming. In fact, I hate computers in general — yet they’re my livelihood. If I could snap my fingers and kill ever computer in the world… SNAP!

      • Wyrd Smythe

        Well, hating the central aspect of your livelihood sucks! You must be looking forward to retirement!

      • Anonymole

        5 more years.

        I got to thinking after my response…

        Does the coal miner love coal? The wheat farmer love wheat? The garbage man love garbage? The milkman love milk? What those occupations feel like is how computers feel for me.

        If they weren’t my livelihood — I might appreciate the more. Hell, I’m ecstatic that I have one that will help me write my fiction. But the daily code I write — I penned a popular post years ago “programming is the new salt mine.” Still get hits on that.

      • Wyrd Smythe

        Heh, yeah, that’d be a pretty weird coal miner. (Not that they don’t exist, I assume.)

        It took me a long time to appreciate the blessing of loving my work. I didn’t realize how uncommon that was until I’d been in the workforce awhile and heard enough stories. I was going to blame it on modern times, but the occupations you listed are quite ancient. Work has always been a bummer!

      • Anonymole

        And actually, that’s just the official “age”. There’s no way in hell I’ll be able to actually retire at 65. I’ll be working — coding — until the day I die, just to make ends meet.

      • Wyrd Smythe

        Damn, that double-plus sucks. 😦

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        Before you snap, please kindly save me the special computer named Rachel.

        Yours sincerely,
        Code Runner SoundEagle

      • Anonymole

        Consider her securely stashed, awaiting your passcode for retrieval.

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        Thank you. The passcode is the 100th word of the first paragraph of the 12th section named “Denouement: Democracy, Education, Legislation & Sustainability” within my extensive and analytical post entitled “💬 Misquotation Pandemic and Disinformation Polemic: 🧠 Mind Pollution by Viral Falsity 🦠“.

        Yours sincerely,
        Code Runner & Passcode Racer SoundEagle

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        Given that your one-word code-handshaking reply has one more alphabet than the passcode does, one wonders whether you have indeed identified the intended passcode in the said location.

      • Anonymole

        You’re making me spit my beer all over my keyboard…

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        FunnyHaHaHa” has the right number of alphabets for our passcode-handshaking with respect to your releasing and my retrieving the said computer.

        Yours sincerely,
        Code Runner, Passcode Racer & Rachel Saver SoundEagle

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        You came very close to locating the passcode, as the preceding word, namely the 99th word of the first paragraph of the 12th section named “Denouement: Democracy, Education, Legislation & Sustainability” within my extensive and analytical post entitled “💬 Misquotation Pandemic and Disinformation Polemic: 🧠 Mind Pollution by Viral Falsity 🦠“, indeed has 12 alphabets matching your one-word passcode-handshaking “hahahahahaha“.

        That you (sub)consciously gravitate to the 99th word rather than the 100th word is quite telling psychologically, or even existentially, especially given the stark contrast between the two words.

        Yours sincerely,
        Code Runner, Passcode Racer, Rachel Saver & Passcode Checker SoundEagle

      • SoundEagle 🦅ೋღஜஇ

        Dear Anonymole,

        There is a typo in my previous comment: I meant “Handshake Checker” not “Passcode Checker”.

And what do you think?

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: