Message Arity

There is another long-standing knotty BOOL issue that I’ve recently resolved. It has to do with the arity of functions. The original syntax of BOOL assumes the compiler knows how many arguments go along with any given Message. There is always at least one argument, the target object of the Message.

The problem is that how many other objects are involved depends on the the Message. For example, an add: Message has its target and one other object (as do nearly all math, relational and logical operators). But some Messages, sqrt: for example, only have their target.

The compiler needs to know this to build the Message properly!

This is related to the previous topic about Actions, because dealing with callable units is where arity becomes an issue. Programming languages use a variety of syntax techniques to indicate how many arguments go with a sub-routine invocation. The most common, perhaps, is enclosing them in parenthesis. (This is so common that f() is understood to refer to some kind of function.)

In BOOL, Actors invoke Actions and “know” about them. The signature of a Generic Action specifies exactly what it takes.  The compiler can reference the Action to discover how to build the Actor. The issue of arity doesn’t exist for Generic Actions.

Messages present a problem, though. Consider the following example:

set: c  add: a b

This sets the object ‘c’ to the value obtained by adding objects ‘a’ and ‘b’. It so happens that both the set: and add: Messages have two parameters, but without knowing that, it’s impossible to know that ‘b’ belongs to the add: Message.  If the set: Message took three arguments and the add: Message took only one, then it would!

The only solution is that the compiler needs to know the arity of all Messages. Which first means it somehow has to have or get a list of every possible Message! It also means that the arity of a given Message is fixed. That’s probably not a bad thing; it could be confusing having one Message with different parameter counts, but method overloading frequently creates that scenario anyway.

After years, no decades, of dithering, I’m finally biting the bullet and (reluctantly) adding one more syntax character to BOOL. It does completely resolve the arity crisis at the cost of adding some verbose ugliness to the language.  Although given that’s actually one of BOOL’s design goals, I’m not sure why I’m complaining.

In any event, now the two Messages above would be written:

set: c  add: a b;;

The addition is the two semi-colons at the end. Each one terminates a Message. That means the number of colons and the number of semi-colons must match (kind of like parenthesis, which in fact is exactly what’s disguised here).

I’ve already updated the previous examples, which is why this being a new thing might seem a surprise. But it is.  I’ve toyed with the idea, back and forth, a lot over the years, but hoped to find a better solution.

Having the compiler know about Messages is a worse architecture, so there we go.

(I did toy with the idea of having every Message just take a single list of one or more parameters, but it didn’t actually change the problem. You couldn’t tell which list some objects were supposed to be on!)

This is one more of those real blocker topics that’s prevented progress for all of BOOL’s life.  It’s very sweet to finally be resolving some of these issues!!

%d bloggers like this: