Tag Archives: List

Last Word on Lists

One of the more unusual aspects of BOOL is its List notation, which is somewhat similar to how Python uses indentation for code blocks. (In fact, the List Character can be defined as the TAB character, which makes BOOL look very similar.)

This post discusses current (and presumed final) List syntax, including Gated Lists.

Continue reading →


Arrays Yet Again

But hopefully once and for all. What started in Disarray, and then seemed briefly Final, yet was still Revisited, has, just perhaps, at last settled into a design that doesn’t nag me. (Or, at least, doesn’t nag me so much I find myself constantly chewing on the bone.)

It feels that I have finally solved how I want BOOL to do arrays!

Continue reading →

BOOL Python Binding

Again the retirement free time, the pleasure of Python, and perhaps it just being the right time, conspire to move the BOOL project forward into new territory. The Reference Implementation is coming along nicely on several fronts. The design of various objects has become solid enough to use in writing bits of code.

In particular, it’s possible to discuss how objects are represented in Python, and it’s possible to start thinking about the code that works with those objects. With the BOOL source definition becoming more stable, it’s also possible to start thinking about compilers. This post introduces these things; in some cases, in some detail.

For dessert, I’ll briefly mention a BOOL XML binding.

Continue reading →

Actions, part 4

The last topic to cover in this series concerns Action parameters. There are several basic categories of Action parameter; which one is most appropriate depends on how the Action is used. In turn, the category used may have consequences on how the Action is invoked.

The strictest category forces parameters to a specific Model. At the other extreme, the generic category allows any type of parameter. Intermediate categories restrict inputs to a class of types.

Continue reading →

Gated Lists (update)

I’ve changed my mind about the Gated List syntax. (These mind-changes are a key reason BOOL design is endless!) The idea of binding a label to the first statement in a List to indicate a Gated List just didn’t make good sense to me.

The problem is two-fold: Firstly, a key reason for Gated Lists in the first place is their use as named Action clauses. When the label is buried in the List (because it now belongs to the first List member), there’s no sensible way to migrate the label to the List. Secondly, a label on the gate expression really makes no sense and has no value.

So I’ve come up with something new!

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 →

Gated Lists

I think I just solved a long-open issue in BOOL regarding conditional Lists. It’s something that’s been nagging me a long time. For one thing, it’s one place that’s line-sensitive, and BOOL tries to avoid that. (Actually BOOL is very line-sensitive, but not that way.)

The other thing is that it conflated two things into one, and that’s also to be avoided. Clarity is everything, and not overloading concepts is an important part of clarity. (Orthogonality is another clarity goal that BOOL considers important.)

The background for this goes back to a BOOL primary design goal and technique.

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 →