A void attribute declares a place for an argument. It lets us form an object before supplying all the objects it needs. That can look like a Java reference initialized to null, which prompted this discussion. The difference becomes clear when we apply an argument: EO copies the object and fills a vacant attribute in the copy.

In EO, an exclamation mark after a binding asks for a dataized result:

5 > five!

The name is five; ! is syntax attached to the binding, not part of its name. The important consequence is that five behaves as bytes, rather than preserving the interface of the original number. The spelling is small, but its history makes it easy to read too much into it.

If an EO object has three attributes, does dataization turn all three into bytes? This question exposes a common misunderstanding. Dataization obtains the data that an object represents. Serialization encodes a chosen representation of an object’s state, with rules for such things as field names, ordering, and nested objects. The dataized object does not supply such an encoding.

A unit test in EO is an attribute of the object it tests, and it comes in exactly two kinds: the object can do something, or it cannot. Two arrows spell the difference, ++> and -->, and since the end of July a lint refuses to let the name of a test disagree with the arrow that declares it. It reads like bureaucracy. It is the cheapest design review we have.

Four years ago we introduced the error and try objects: error wrapped an object and threw it up the stack, try caught it, extracted the payload, and ran a finally block. It worked, but it was Java smuggled into EO — 𝜑-calculus has no exceptions to throw and no stack to unwind. What it does have is ⊥, the bottom — a computation that terminated. Recently we deleted try and error and gave the bottom a spelling of its own: the letter T, which we call the terminator.

Most languages keep unit tests at a distance from the code they verify: a parallel source tree, a mirror class with a Test suffix, a framework that finds tests by annotation or naming convention. The distance is the problem: mirrors go stale, tests drift, and “where are the tests for this?” becomes a question worth asking. In EO we reduced the distance to zero. A test is an attribute of the object it tests, declared inside the object, in the same file, in the same scope.

In 𝜑-calculus, a formation may be applied on the spot: the expression ⟦a ↦ 7, x ↦ ∅⟧(x ↦ 42) forms an object with one void attribute and immediately supplies the argument. EO had no way to say this. A formation first had to receive a name, and then a separate application had to repeat that name. Recently we closed the gap with a new syntax element: a line that starts with |, which we call a pipe.

People keep asking us why EO exists, since the world hardly needs yet another programming language. It is a fair question, and it deserves a straight answer. EO is not trying to out-comfort Java or out-hype Rust. It is a research instrument pointed at one old, specific, and still unsolved problem: object-oriented code is pleasant for programmers to write and expensive for computers to run.