How Programming Language Syntax Catches Bugs

Smalltalk’s Syntax: More Than Just Elegance

Photo by Lesly Juarez on Unsplash

Programmers love arguing about programming tools, as well as the syntax of different programming languages.

In the case of the former, there are usually arguments about capabilities and features, but when it comes to syntax, it usually boils down to subjective reasons and ultimately, familiarity.

Most programmers are familiar with ALGOL-based syntax, which is also used by C-like languages. When someone sees a language like that, it’s usually considered “good” syntax, regardless of any objective criteria.

Everyone knows that the code below is a function call, even without knowing which programming language it is from.

f(a, b, c)

But is this the best syntax for representing this concept, or do we just like it because we’re familiar with it?

We can ask this question from different points of view, like readability, simplicity (how easy it is to parse), extensibility (how easy it is to define user-defined macros), and correctness too.

Now, I’ll focus on the latter now. Can syntax prevent or catch bugs?

Let’s take the following JavaScript function, that takes four parameters.

function transfer(account1, account2, amount, currency) {
    // ...
}

The implementation doesn’t matter, we just want to call it someplace else.

Often we’re not sure how many parameters a function takes, so we might call it with too few or too many arguments.

transfer(account1, account2)

In JavaScript, when we call a function with fewer parameters, the missing ones become undefined, possibly causing bugs later on. But when we call it with more parameters, those are ignored, which is often not what we want.

Python is more strict, and both cases would cause a runtime error.

TypeError: transfer() missing 2 required positional arguments: 
'amount' and 'currency'  

Or

TypeError: transfer() takes 4 positional arguments but 5 were given

If you have a static type checker or linter, then this is not a problem. But you don’t really need one to prevent these kinds of problems. Syntax alone can take care of it.

Meet Smalltalk’s Syntax

Smalltalk has a peculiar syntax that many people don’t know. Since the language is fully object-oriented, everything happens through message sending (polymorphic method calls).

But there are three different types of messages, and the type of message also defines the precedence rules. Unary messages come first, then binary messages, and finally keyword messages.

Unary Message

A unary message is parameterless, we could say its arity is zero.

5 factorial

The above would look like the one below when using a more familiar syntax.

5.factorial()

But in the Smalltalk version there are no empty parentheses to shove the parameters into, so you can’t really accidentally pass any arguments.

Binary Message

Binary messages use one of the predefined symbols, such as mathematical operators like addition or multiplication.

1 + 2

This looks exactly like it would in another language, but what it really means is a method call on the object 1 with the parameter 2.

So this is how you would translate it into a familiar syntax:

1.+(2)

In case of binary messages, it’s easy to see how many parameters to pass (it’s always one), so there’s no way to call + with more or fewer arguments than it expects.

Keyword Message

Keyword messages are the most flexible, since they can take any number of parameters.

Here are some examples of keyword messages with one, two, and three parameters. The third example uses a combination of all three message types.

colletion add: 'apple'

dict at: 'key' put: 'value'

Rectangle origin: 10 @ 20 extent: 100 @ 50 color: Color red

And below you can find the translations into a well-known syntax.

collection.add('apple')

dict.atPut('key', 'value')

Rectange.origin(new Point(10, 20), new Point(100, 50), Color.red())

Let’s take the second example: putting a value under a key in a dictionary or hashmap.

In the Smalltalk example, at:put: is the name of the keyword message. And interestingly, the parameters are embedded in the message name.

So the question is, can you get arity bugs, that is, using a keyword message with too few or too many parameters than it expects?

Here is the account transfer example written in Smalltalk’s syntax.

transferFrom: anAccount1 to: anAccount2 amount: amount currency: currency
    "..."

The name of the keyword message is transferFrom:to:amount:currency:, and the number of colons clearly defines how many parameters the message takes.

If I wanted to call it with more arguments than it expects, I would have to use a different name, and if I wanted to call it with fewer, then some parameters would be left empty.

bank transferFrom: source to: destination amount: 100 currency: 'USD'

If I miss one parameter, it will be instantly noticeable, and adding more is also physically impossible since there is nowhere to put it.

Image by the author

In the former case, the code won’t even compile, but not because of a type system, but because of a syntax error coming from the parser.

The Close

That’s the beauty of Smalltalk’s syntax, it’s not just readable, it also eliminates a whole class of programming errors — arity bugs.

Argument count mismatches are common in dynamically typed languages, but with the right syntax, they can be caught as early as possible.

[embed]What Makes Smalltalk Unique? Other than Lisp and Forth, Smalltalk was the third language that significantly shaped my understanding of programming…code.likeagirl.io

— Aleena