Message Arity (revisited)

I recently determined to use a trailing marker — a semicolon — to close the list of arguments due a Message. But after using it for a while, I’ve decided that this:

.   set:x add: mul:a b; div:c d; ;;

Is butt-ugly and has to change. Since I still think registering Message arity is an even worse option, I’ve had to take the only other real option: assuming Message arity.

One thing that has become apparent is that most Messages have a target object and a parameter object (arity: two). Nearly all the rest have only the target object (arity: one). A very small number have the potential for more than one parameter, but nearly all of those work fine with a single parameter List (rather than a list of parameters).

The bottom line is that — with a small sacrifice of a handful of Messages that work best with multiple, distinct parameters — Messages can be assumed to have an arity of one or two. That means BOOL can assume an arity of two if there exists a suitable way of signalling the exception case (an arity of one).

So, I’m going to try using a semicolon to replace a missing parameter and signal a Message with no parameters. So far it seems sensible; the real test will be using it over time.

The Message syntax is now:

msg: {target-object} {parameter-object}


msg: {target-object} ;

The parameter-object can be a List of objects or a single object.

Now the example above looks nice and clean:

.   set:x add: mul:a b div:c d

Here’s an example using arity=1 Messages:

.   set:x sqrt: add: cos:angle1; cos:angle2; ;

The sqrt: and cos: Messages have only a target object, so they require semicolons to (take your pick) “stand for” the missing parameter or “close” (early) the list of Message arguments. The semicolon is a distinct token, so white-space is not required (but is allowed) on either side.

I was never really comfortable with the semicolon as an end-of-list marker. In small doses it was actually kind of nice, but in multi-Message examples (such as used here) it generated a lot of visual noise. (What was nice was the symmetry of having a colon begin the list of arguments and a semicolon end them.)

There aren’t too many Messages with an arity of one. Here’s an off-the-top-of-my-head list of some:

  • not: — logical inverse
  • true: false: — logical tests
  • neg: abs: ceiling: floor: — arithmetic functions
  • sqr: sqrt: log: — mathematical functions
  • sin: cos: tan: — trigonometric functions
  • close: bof: eof: err: — file functions

Which leaves Messages that would benefit from distinct, multiple arguments. A good example is an open: (file) Message. One might normally look something like this:

open: {filename} {RW-mode} {various-options}

Options might include line-end handling, binary modes, buffer sizes and more. In many languages named, optional parameters provide a way to pass extra information to a complex function. In others, separate functions allow configuring file behavior. There are many ways to attack the problem.

In point of fact, BOOL file-handling is likely done using System objects, and there is a potential to manipulate the object’s properties prior to opening a file (or perhaps even during). My guess is I won’t miss the ability to have more than two arguments for a Message!

%d bloggers like this: