++> 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.
Most testing frameworks treat failure as an afterthought.
In JUnit, “this works” is an expression,
while “this dies” is an expression wrapped in a lambda
and handed to assertThrows.
In Python, the first is a line, the second is a with block.
The asymmetry is small, but it is charged on every negative test,
and the tests nobody writes are always the ones that cost extra.
In EO both cost one arrow.
Here is the whole test that i64 refuses to divide by zero,
from i64/div.eo:
2.as-i64.div 0.as-i64 --> stops-on-division-by-zero
The --> suffix declares a throwing test attribute (spec, §6.3):
sugar for [] -> name, exactly as ++> is sugar for [] +>.
Whatever stands to the left becomes the @ of a parameterless formation,
and the test passes when dataizing that formation
terminates.
The transpiler reads one character —
the - in front of the attribute name —
and emits assertThrows where it would otherwise emit assertTrue.
Nothing changes when the test needs more room.
The arrow can head its own line, with the body indented below,
as in malloc.eo:
malloc.for --> stops-on-overflowing-a-string-block
"Hello"
m.put > [m]
"Much longer string!"
There is no expected, no catch, no exception class to name.
There is nothing to name, because
a forced bottom carries no payload
that a test could match on.
The assertion is the arrow.
Since 29 July the bad-test-name lint checks
the name of every test against the arrow that declares it:
+> test must be named can-… or accepts-…;-> test must be named cannot-…, rejects-… or stops-on-….So this is a defect, and the lint says so:
front --> can-take-a-fractional-index
Note what is being checked. Not that the name matches some approved prefix — that the prefix matches this arrow. A negative test wearing a positive name is a contradiction between two halves of the same line, and one of the halves is wrong. Usually it is the arrow, pasted from the test above it.
The obvious reason is uniformity.
eo-runtime holds 1479 positive tests and 147 negative ones;
all but one of the positives begin with can-,
and 141 of the negatives begin with stops-on-,
because termination is what the runtime does when asked for nonsense.
A reader scrolling through recovered.eo
meets a column of sentences that all open the same way,
and a grep for stops-on returns every negative test in the language.
The better reason is discipline.
A prefix is a grammatical obligation:
it makes the object the subject of a sentence
that the author now has to finish.
“malloc stops on overflowing a string block.”
“recovered can keep the value when not terminated.”
Names like test1, works, bug-4212 and it-works
cannot survive that requirement,
because none of them is the tail of a sentence about anything.
The obligation pushes back on the test, too.
If the sentence needs an “and” to finish,
the test is checking two behaviours and should be two tests.
If no subject fits in front of it,
the test is not about the object it lives in.
If the sentence can only be finished by restating the code —
“can call put with a long string” —
then the author knows what the test does
but not what it proves.
Naming is where a bad test declares itself first,
earlier than coverage reports and much earlier than a failure,
and a prefix is what makes the declaration audible.
None of this is new advice; every team has a naming convention. The difference is where it lives. A convention in a style guide is enforced by whoever reviews the pull request, on the days they have the patience. This one is enforced by the build, in every project that compiles EO, which is why the prefix list is short and closed: five words, no per-project dialects.
The naming lint has siblings.
unit-test-missing complains when an object has no tests at all,
unit-test-without-phi when a test binds attributes but never @,
and wrong-test-order when tests sit above the code they verify
instead of below it.
The parser adds its own: a test attribute is legal only as a direct child
of the top-level object, exactly one blank line must precede it,
and an atom’s body may contain nothing but its voids and its tests
(spec, R-6.3.1, R-6.3.3, R-6.5.3).
Together they leave one shape for a unit test, which is the point. A test name is the only documentation guaranteed to be read at the exact moment it matters — when it fails — and rigidity is cheap in that spot.
That’s all for today.
]]>⟦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.
A pipe line applies arguments to the object declared just above it, at the same indentation:
[x] > foo
x.plus x > @
| 5 > foo5
The formation foo doubles its argument;
the pipe applies 5 to it and names the result foo5.
The | reads as an arrow pointing up:
“take the object above, give it 5, call the result foo5.”
The semantics is untouched —
the pipe desugars into a plain application,
and the program above compiles to exactly the same XMIR as:
[x] > foo
x.plus x > @
foo 5 > foo5
Sugar, pure sugar. So why bother?
Because the name may not exist.
The >> suffix auto-names an abstract object
when a meaningful name would add nothing,
and the generated name is deliberately untypeable.
Until now, such an object could only be passed somewhere as an argument;
it could not be applied, since application requires a name to repeat.
The pipe needs no name:
[a b] >>
a.plus b > @
| 2 3 > pair
This is a lambda expression applied at the place of its definition — what the original issue asked for: anonymous formations working as functions in Haskell or lambdas in Java.
Consecutive pipes stack into left-associated applications:
[x] > foo
x > @
| 1 >>
| 2 > result
Here result is (foo 1) 2.
Each pipe in a chain is an object of its own
and must carry a name,
because the next pipe refers to its predecessor by it —
>> does the job when you don’t care.
When arguments don’t fit on one line, the pipe takes them vertically, exactly as any application head does:
[x y] > add
x.plus y > @
| > sum
2
3
And since a pipe application is a complete value,
a .method may follow it:
[x] > foo
x > @
| 5
.neg > y
The pipe is picky about its predecessor.
It must be a formation or another pipe,
and it must be named —
either explicitly with > name or automatically with >>:
6 > six
| 5 > n
This is rejected: six is a number, not a formation.
A pipe with nothing above it is rejected too,
and so is a pipe after a .method line:
once the dot has dispatched an attribute,
the formation is no longer the object in hand.
The runtime library already uses pipes,
mostly for one pattern:
a local recursive helper, defined and called in one breath.
This is how number.power computes an integer exponent:
[b n] >> ipow
if. > @
n.eq 0
1
if.
is-integer. (n.div 2)
half.times half
b.times
ipow b (n.minus 1)
ipow b (n.div 2) > half
| base (abs expo)
The helper stays anonymous to the enclosing scope,
yet recursion works:
>> ipow gives the formation a file-local handle,
the body calls itself by it,
and the pipe fires the first call with the actual arguments.
Definition and invocation sit together;
the reader never hunts across the file
for the place where ipow is used.
In 𝜑-calculus, formation-with-application was there all along. Now EO can write it too, without inventing a name for the middle.
That’s all for today.
]]>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.
Here is an object with two tests:
[x] > square
x.times x > @
eq. ++> can-square-a-negative
square -3
9
eq. ++> can-square-zero
square 0
0
The ++> suffix declares a test attribute (spec, §6.3):
the expression to its left is the whole body of the test,
and the test passes when that expression dataizes to TRUE.
There is a second kind, -->, for when termination is the expected outcome —
we met it earlier today:
2.as-i64.div 0.as-i64 --> stops-on-division-by-zero
That’s the entire arsenal:
a test either evaluates to truth or is expected to die.
No runner in sight, no annotations, no imports;
even the assertion “library” is just eq., lt., and friends —
ordinary objects from the runtime.
The suffix ++> name is sugar for [] +> name:
a parameterless formation, bound to the enclosing object
under a name marked as a test.
In XMIR the test is a binding like any other,
distinguished only by a + (or -) in front of its name.
The compiled object carries its tests
the way it carries every other attribute,
and running one means taking that attribute and dataizing it —
which is precisely what the generated JUnit method does,
one assertTrue (or assertThrows) per marked binding.
Being an attribute designs the test for you.
A test is a formation whose @ is a single expression,
so its verdict is one boolean, not a report of several.
It has no parameters and no shared fixtures;
whatever it needs, it names inside itself,
as i64.div does when checking division by one:
++> can-divide-by-one
eq. > @
dividend.div 1.as-i64
dividend
-235.as-i64 > dividend
And since tests are siblings of the object’s internal attributes, they may reach helpers directly — the “should I test private methods?” debate has nothing left to attach to.
Some objects are atoms: their bodies live in Java or JavaScript, not in EO.
An atom’s EO body may contain nothing
but its void attributes and its tests (spec, R-6.3.1).
Here is recovered, abridged:
[] > recovered /A
? > value /A?
? > alternative /A
eq. ++> can-fall-back-to-the-alternative-when-terminated
recovered
2.as-i64.div 0.as-i64
7
7
eq. ++> can-keep-the-value-when-not-terminated
recovered
42
7
42
The implementation is elsewhere; what the EO file states is the signature and the behaviour — an executable contract, sitting exactly where a reader looks first.
Putting tests near code is not new.
D compiles unittest blocks written inside classes and structs;
Pyret attaches a where: clause of examples to a function;
Python runs examples found in docstrings with doctest,
and Rust does the same with documentation tests;
Clojure’s with-test hangs a test function on a var’s metadata.
Yet in every one of these, the test is a guest:
a block, a clause, a comment, a metadata entry —
something the toolchain knows how to run
but the language does not know how to hold.
In EO the test is an object,
and an attribute of the object it tests:
present in the object model, in the XMIR, in the compiled artifact,
reachable by take like everything else.
As far as we know, no other language does this.
If we are wrong, tell us in the comments —
we would genuinely like to meet the precedent.
That’s all for today.
]]>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.
The new syntax element is one reserved glyph,
mapped to ⊥ in XMIR:
T > x
The terminator is a value with no data and no behaviour. It may be named, stored, copied, and passed around like any other object; a copy of it is itself, and every attribute taken from it is itself again, so it flows silently through dispatch and application. It detonates only when something forces it — tries to dataize it. Then the program stops, for good: no object catches a forced bottom, because catching is not a thing anymore.
A terminator may carry a cause:
T "this can't happen"
The first object applied to a bottom is remembered and printed when the bottom is finally forced. That’s all the cause does. EO code can’t read it back, match on it, or re-throw it — it is not an exception payload, it is an epitaph.
This is how the tuple object defines its empty companion:
tuple > empty
T
"Can't get tail from the empty tuple"
T
"Can't get head from the empty tuple"
0
The head of the empty tuple is a terminator.
Building the tuple costs nothing and fails nothing;
only the code that forces empty.head
dies with the message above.
Taking a void attribute that nobody filled
now yields a terminator instead of raising an error.
This one rule replaces the whole optional-argument machinery.
Consider i64.div:
[n x cant-divide] > div
if. > @
x.as-bytes.eq 00-00-00-00-00-00-00-00
cant-divide
"i64 cannot be divided by zero"
...
The third void, cant-divide, is a fallback the caller may supply.
If they don’t, taking it yields ⊥,
the message lands in its cause slot,
and division by zero terminates the program:
2.as-i64.div 0.as-i64
If they do, the same application invokes their handler instead:
2.as-i64.div
0.as-i64
"no luck" > [message]
This dataizes to "no luck".
One mechanism, two behaviours, zero exceptions.
Sometimes a failure is expected and the show must go on.
For that single purpose there is the recovered atom:
recovered
2.as-i64.div 0.as-i64
7
It resolves the first attribute to its normal form;
if that turns out to be a bottom, it behaves as the second,
otherwise as the first.
This dataizes to 7.
Note what recovered is not:
it sees no cause, filters no “exception types,” runs no finally.
When both attributes terminate, the result is still a bottom,
which only an outer recovered may intercept —
a bottom that nobody recovers ends the program.
Since termination is now a first-class outcome,
unit tests assert it with the throwing-test suffix -->,
a sibling of the truthy ++>:
2.as-i64.div 0.as-i64 --> stops-on-division-by-zero
The bottom was in 𝜑-calculus from the very first paper;
try and error never were.
Now the language agrees with its own semantics,
and the price of that agreement is one letter.
That’s all for today.
]]>Objects earn their keep at design time. Abstraction, encapsulation, and polymorphism let us hold a large system in a small head. The bill arrives at run time. Craig Chambers and David Ungar put it plainly back in 1991: object-oriented languages “contain a number of features that make programs easier to write but slower to run.” Urs Hölzle explained why compilers struggle to help: procedures are smaller and calls more frequent than in C or Fortran, and dynamic dispatch hides the target of every call, so inlining and interprocedural analysis simply do not apply. Karen Driesen and Urs Hölzle then measured the damage: C++ programs spend a median of 5.2% and up to 29% of their time executing dispatch code, and when every function is virtual, the median rises to 13.7% and the maximum to 47%. In dynamic languages such as Python the same story is told louder, since there an attribute access is a dictionary lookup and a method call is a small ceremony.
We once measured this ourselves, implementing the same Fibonacci algorithm twice in each language: once with functions, once with objects. The table shows millions of CPU instructions spent computing the 32nd Fibonacci number:
| Language | w/functions | w/objects | Ratio |
|---|---|---|---|
| Java | 41 | 4,589 | 109x |
| C# | 36 | 5,785 | 157x |
| C++ | 93 | 7,203 | 76x |
| Go | 39 | 15,907 | 403x |
Same algorithm, same machine, same compiler — the only difference is objects instead of functions. This is the tax we pay for abstraction, and we pay it on every core, in every data center, every day.
The problem is not new, and the people who attacked it were not weak.
Peter Deutsch and Allan Schiffman opened the campaign in 1984 with inline caching in Smalltalk-80: remember where the last lookup landed, and in nine cases out of ten the next one lands there too. Chambers and Ungar answered in 1989 with customization in SELF: compile a separate copy of each method for each receiver type, so that within a copy the type is a compile-time constant. Hölzle generalized the cache in 1991 into polymorphic inline caches that hold several targets per call site, then in 1994 added type feedback: let the runtime observe actual receiver types and feed them back to the compiler, which inlines the hot target behind a guard. Jeff Dean, David Grove, and Craig Chambers gave compilers class hierarchy analysis in 1995; David Bacon and Peter Sweeney sharpened it in 1996 into rapid type analysis, which prunes the call graph down to classes actually instantiated. Julian Dolby inlined whole objects into their containers in 1997; Jong-Deok Choi and colleagues brought escape analysis to Java in 1999, so that objects provably local to a method could live on the stack; Kazuaki Ishizaki and colleagues devirtualized calls with code patching in 2000; Christian Wimmer and Hanspeter Mössenböck fused parent and child objects at run time in 2010; Anders Møller and Oskar Veileborg eliminated the abstraction overhead of Java stream pipelines in 2020.
This list is a fraction of the literature — a fuller chronology is what our papers page and lectures keep growing. Yet, to the best of our knowledge, only a few of these techniques run inside Clang and OpenJDK today.
Because in Java, C++, and Python, almost every one of those optimizations is a bet the language allows to lose.
A class loaded at run time can extend the hierarchy
after class hierarchy analysis has finished,
so a devirtualized call needs a guard and machinery to undo itself.
Reflection can reach a method that no static analysis ever saw,
so dead code is never provably dead.
Mutation means a fact proven about an object at one program point
has expired by the next.
Even an innocent annotation can break an optimizer:
inline a method into its caller,
and whatever semantics a framework attached to @Transactional
silently disappears.
Modern JITs cope by speculating: optimize as if the world were simple, check at run time that it still is, and deoptimize when it is not. HotSpot is a genuine marvel of this kind — but it treats symptoms. The language keeps making promises to the programmer that the compiler cannot verify, so the compiler hedges, and every hedge is a check, a guard, a table, a pause.
Programmers did not wait for the papers to be written. Decades of profiling taught the OO community one practical lesson — objects are slow — and the community answered with a silent agreement: avoid them.
Open any performance-minded Java codebase and you will find ALGOL wearing Java syntax: static methods instead of objects, NULL instead of an object that says “not found”, global state instead of composition, primitives and arrays instead of types, singletons, utility classes, empty constructors, and allocation treated as a sin. None of this is ignorance. It is self-defense: the compiler cannot make objects cheap, so programmers make them rare.
Every such trick buys speed and pays with design. David West called the result “a pale shadow of the original idea” of objects, and the shadow is what we now maintain: code that reads poorly, changes reluctantly, and greets every refactoring with a production bug. The performance problem of OOP has quietly become a quality problem of software.
EO takes the other road: change the language, not the compiler.
EO is a small object-oriented language
whose semantics is 𝜑-calculus,
a formalism where a program is nothing but objects:
formation, application, dispatch, and data.
There are no classes, no inheritance, no statics, no null,
no mutation, no reflection, no annotations,
and no flow-control statements —
if, while, and seq are objects too.
We expect any object-oriented language to be reducible to EO. This is not a hypothesis we sit on: jeo already disassembles Java bytecode into EO, and hone runs the full round trip — Java to bytecode to EO to 𝜑-expressions, then normalization by formal rewriting rules whose confluence is proved in Lean, then back to bytecode. The preliminary results are promising: we reproduced the stream-pipeline fusion of Møller and Veileborg, but as rewriting rules over 𝜑-expressions rather than a special-purpose bytecode analysis.
Since EO is simple, the reduction target is simple, and this is where the strategy points: build a compiler — perhaps with a virtual machine behind it, perhaps one day with a dataflow processor under it — that turns EO into binaries running faster than what javac, gcc, or CPython produce from the original source.
Our belief stands on facts about EO that Java, C++, and Python cannot offer.
First, all objects are immutable. An attribute is bound once and never reassigned, so any expression may be computed once and its result shared, caching is always sound, and aliasing analysis is unnecessary because there are no writes to alias. What escape analysis spends its budget proving about a Java object, the EO grammar simply forbids to be otherwise.
Second, type inference is total. There is no reflection, no type casting, and no run-time class loading, so the object graph is closed at compile time and every dispatch resolves statically to one target. No virtual tables, no guarded devirtualization — a call compiles to a jump, and nothing in the language can invalidate it later. Class hierarchy analysis and rapid type analysis speculate about this world; EO is this world by construction.
Third, there is no global state. Every block of memory in EO is strictly scoped:
malloc.of
8
[m]
m.put 42 > @
The eight bytes exist only inside the scope object, and when its dataization ends, the block is reclaimed. An object’s lifetime is written in the source, escape analysis reads directly off the program text, and leakage is impossible because there is no global to park a reference in.
While building the compiler we keep finding smaller gifts
of the same nature.
Control flow is objects,
so a program is one expression graph
that a dataflow machine can evaluate without reconstructing
a control-flow graph.
There is exactly one data primitive — bytes —
and number, string, and bool merely decorate it,
so rewriting rules stay uniform.
Decoration replaces inheritance,
so “super” is just another attribute, statically known.
And since every object lives in its own file
and a package is itself an object,
whole-program analysis actually sees the whole program.
We have no proof — only the bet, the pipeline, and early numbers. The language is still moving: its grammar, its semantics, and the calculus itself are being revised as we learn. Normalization may inflate code the way aggressive inlining famously did; reduced Java that leans on reflection may arrive in EO stripped of the very guarantees we brag about; the dataflow hardware may remain a patent portfolio. These are the risks of a research direction, and we accept them.
For forty years, compilers have been taught to guess what object-oriented programs will do and to apologize at run time when they guess wrong. Our wager is that the guessing was never necessary — it was the languages that made it so. EO is our attempt to build the language that doesn’t.
That’s all for today.
]]>.eo file said it was.
If you wanted number to know how to raise itself to a power,
you either grew number.eo until nobody could read it,
or you parked the operation in some other object with a made-up name.
We took a third road:
an object and the package named after it are now the same thing,
so number is defined by number.eo and by every file under number/.
The EO runtime used to ship packages called ms, tt and ss.
They held mathematics, text and sequence helpers respectively,
and their names were abbreviations that meant nothing to anyone
who had not read the source.
Raising two to the fourth power looked like this:
ms.power 2 4
Trimming a string looked like this:
tt.trimmed " hello "
Every one of those names was an apology.
ms existed only because power had to live somewhere,
and number.eo was already four hundred lines long.
The alternative was worse: fold power, sqrt, sine, cosine,
arc-sine, radians, degrees and twenty more into number itself,
and end up with an object whose definition nobody could hold in their head.
This is an old tension. A small object is readable but poor. A rich object is useful but unreadable. Most languages resolve it by letting one type live in many files; EO had no such mechanism, because a file was an object.
Let the package do the work.
When the runtime is asked for an attribute that an object does not have, it looks for an object of that name in the package named after the object’s type, and if it finds one, it binds the receiver as the first argument. So this:
2.power 4
means exactly this:
number.power 2 4
Both forms compile, both run, and both give 16.
The object power lives in the file number/power.eo,
which declares +package number and defines a single object:
[num x] > power
...
Nothing was added to number.eo.
The number object is still a small thing that wraps some bytes.
But its surface now includes everything in the number/ directory —
twenty-five files at the time of writing,
next to thirty-four for string and twenty-three for tuple.
The ms, tt and ss packages are gone.
The rule is uniform, so it works for operations of any arity.
abs takes one argument and reads as -3.abs:
[num] > abs
if. > @
value.gte 0
value
value.neg
number num.as-bytes > value
While contains takes two and reads as "hello".contains "h":
[text substring] > contains
...
The receiver is always the first argument.
There is no self, no this, and no special position —
just a plain object whose first argument happens to be the thing
you dispatched from.
The part we like most is what this does to the file tree. EO keeps one object per file, and that rule did not bend to make this feature work. Instead, the feature made the rule pay off:
number.eo
number/
abs.eo
cosine.eo
power.eo
sqrt.eo
...
Each extension is a file.
Each file has a name, a docblock, its own tests, and its own history in Git.
Adding an operation to number means adding a file, not editing one.
Two people extending number in the same week
never touch the same lines,
because they never touch the same file.
Nor is the directory reserved for us.
Any object gets this for free.
If you write book.eo, then book/summary.eo with +package book
makes (book "Dune").summary work,
and you never declare that fact anywhere —
the directory name is the declaration.
Two things had to change.
First, attribute lookup.
PhDefault now tries the object’s own package
before it descends anywhere else.
Order matters here.
A string decorates bytes, and bytes has an as-number,
so if the decoratee were consulted first,
"42.5".as-number would parse those bytes as a raw number
instead of reading the text.
The package goes first, then the λ of an atom, then the decoratee,
and a name nobody knows terminates the computation.
When the package does answer, the receiver is bound into α0 —
the first positional attribute, not ρ.
That is what makes 2.power 4 and number.power 2 4 the same expression:
the implicit form fills α0 for you,
the explicit form leaves it for you to fill.
Second, the name number had to mean two things at once.
PhNest is the class that does it:
a single shared instance that stands for both the package and the object.
Ask it for power and it hands out the extension.
Ask it for anything else, or copy it, and it collapses into the plain
number object and delegates.
Because that instance is shared by every reference in the program,
it refuses to be written to —
put fails fast and tells you to copy() first.
This also broke a Java rule we had to route around.
A Java class and a Java package cannot share a name,
and our generated code needed Φ.number and Φ.number.power side by side.
So generated classes keep the EO prefix
while package segments now take EO_:
org.eolang.EO_number.EOpower.
Ugly, invisible, and it works.
Parts of it, yes — and we would rather say so than pretend otherwise.
The rewrite itself is well-trodden.
Uniform Function Call Syntax in D and Nim
turns a.b(x) into b(a, x) whenever a has no method b,
which is precisely the transformation EO performs.
Ada 2005’s prefixed notation does the same with a tighter leash:
Y.Op(...) stands for P.Op(Y, ...),
where P is the package in which the type of Y is declared.
C# extension methods and Kotlin extensions
reach the same syntax through static resolution and an import.
Spreading a type across files is equally old.
Swift extensions and Objective-C categories
let a type’s API grow in files far from its declaration.
Go simply defines methods anywhere in the package that owns the type.
Ruby leaves classes open.
Smalltalk has had extension methods for decades —
in Pharo you file a method under a protocol named after your package,
and String grows a method that ships with your code, not with the kernel.
C# partial classes merge several files into one class outright.
And Elixir has turned the naming into a convention:
String.trim/1, Enum.map/2 — a module named after the data it serves,
subject always first.
What we have not found anywhere is the specific combination.
In every language above, the extension mechanism is announced:
a partial keyword, an extension block, an impl, a using directive,
a protocol whose name starts with an asterisk.
Something in the source says “this is an extension”.
In EO nothing does.
The object and its namespace are not two entities that happen to be related —
they are one name, resolved by one runtime lookup.
number is the object, number is the package,
and the language never asks you which one you meant.
Add a file to the directory and the object grew a feature;
delete it and the feature is gone.
We also could not find a language that pairs this with a one-object-per-file rule. That pairing is what turns the feature from a convenience into a structure. Elsewhere, “split a type across files” is a way to survive a big class. Here, the class is never big: every operation is a file, always, with no threshold to cross and no decision to make about when to split.
So: novel as a whole, borrowed in every part. We will take that.
Honesty demands a note on the price.
Lookup is now a classpath probe,
which is why the runtime caches the result of every probe it makes.
An attribute typo that used to fail immediately
can now travel one hop further before it dies.
And a package that shares a name with an object means
reading number.power requires knowing that number is both —
a small tax on the reader, paid once.
We think a name that means one thing
is worth more than a name like ms that means nothing.
That’s all for today. Next time an object of yours starts feeling crowded, make a directory instead of a longer file.
]]>>> syntax stands for:
it auto-names an abstract object when a meaningful name is unnecessary,
and the compiler quietly generates a random unique one under the hood.
Recently we let this same >> carry a handle of your choosing,
and this small change gave EO a new way to hide things.
We call it “encapsulation by obfuscation”.
Most languages guard a name with a keyword.
Java has private and Swift has fileprivate;
Python merely asks you nicely with a leading underscore.
In each case the attribute keeps its original name,
and enforcement ranges from a compiler error to a matter of etiquette.
The name is still there,
still spelled the way the author spelled it,
and a sufficiently motivated caller (reflection, a mangling trick, a cast)
can almost always reach it.
EO has no visibility keywords, and we did not want to add any.
Yet a .eo file often needs a helper object
that makes sense only inside that file
and should never be addressed from anywhere else.
How do you make something private in a language that has no word for “private”?
You cannot refer to a name you do not know. That is the whole trick.
Consider an object that clamps a number to at most ten, leaning on a small helper to take the absolute value first:
[n] > out
if. > @
(abs n).gt 10
10
abs n
[x] > abs
if. > @
x.gt 0
x
x.neg
The abs object is a true helper.
It exists only to serve out, and it means nothing on its own.
Yet, declared with a plain > abs,
it becomes a public attribute of out,
and any other file can reach it:
(out 42).abs
That call is nonsense, but the compiler happily allows it,
because abs is a visible name.
We would rather it were impossible.
So we change one character:
[x] >> abs
Now abs is a file-local handle.
Inside the file, out still calls it exactly as before.
Outside the file, abs simply does not exist,
and (out 42).abs no longer compiles.
The compiler treats abs as nothing more than a temporary label.
During parsing it assigns the object a deterministic “cactus” name
derived from the line and column where it was declared,
collects a per-file table of handles,
and rewrites every mention of abs to that cactus name.
The name it picks is a🌵6-3 —
an a, the cactus emoji, and the coordinates of the declaration.
What comes out the other end looks roughly like this:
[n] > out
if. > @
(a🌵6-3 n).gt 10
10
a🌵6-3 n
[x] > a🌵6-3
if. > @
x.gt 0
x
x.neg
The helper is still there, still perfectly usable —
out clamps its argument exactly as before,
because both call sites were rewritten to the same cactus name.
But its name now contains 🌵,
and the cactus emoji is deliberately excluded
from the grammar of a valid identifier.
No programmer can type it, in this file or any other.
Another file that tries (out 42).abs finds no abs;
and it cannot ask for a🌵6-3 either,
because it neither knows the coordinates nor is allowed to spell the cactus.
The attribute is not hidden behind a rule that says “do not look”.
It is hidden because there is nothing left to look for.
We are not pretending this idea is new;
it is inherited from decades of language design.
Lisp’s gensym has minted unwriteable symbols since the 1970s,
hygienic macros rename identifiers precisely
so surrounding code cannot capture them,
Python’s double underscore mangles a name into a different one,
and every JavaScript minifier renames locals
so the outside world cannot reach them.
The object-capability model makes the same wager at runtime:
authority you were never handed is authority you cannot name.
What EO does is take that old idea — privacy through an unspeakable name —
and make it the language’s only encapsulation mechanism,
operating at file scope, with no keyword and no annotation.
The compiler obfuscates the name; the obfuscation is the encapsulation.
Hence the honest label.
The pleasant part is that it costs the programmer nothing.
You write a friendly abs and read a friendly abs everywhere in your file.
The obfuscation happens once, at compile time,
and only the compiler ever sees the ugly name.
You get the readability of a normal identifier and the privacy of a secret one,
without a single access modifier.
That’s all for today.
Give >> name a try the next time a helper object should stay at home.
Formatting is a small tax that every project pays forever. Curly-brace languages hand the bill to tools like Prettier, gofmt, and clang-format, each carrying hundreds of options and special cases, because the layout space of C or JavaScript is enormous and full of exceptions. EO has a much stricter grammar, yet the same ambiguity remains at the small scale: an object can be spelled tall or wide, and nothing in the language says which is nicer. We wanted one canonical form, chosen automatically, with no table of options to argue about.
The trick is to stop asking “which layout is correct?” and start asking “which layout is cheapest?”
Give every symbol in the output a penalty. As a first cut:
Then render the object in all of its valid layouts, add up the penalty for each, and keep the one with the smallest total.
Here is an object spelled vertically. It has five indents, so its penalty is 15:
[] > foo
gt. > @
42
bar.hello 88
The same object, folded once, drops to two indents, for a penalty of 6:
gt. > [] > foo
42
bar.hello 88
And squeezed onto one line, it pays for a single bracket instead, a penalty of 7:
42.gt (bar.hello 88) > [] > foo
Six beats seven beats fifteen, so the middle layout wins. Change the weights and you change EO’s taste in code, but the machinery never changes: enumerate, score, choose the minimum.
This approach is unusually comfortable in EO, for reasons that would frustrate it in most languages.
The meaning lives in the tree, not in the whitespace. An EO program is a 𝜑-calculus expression, and its layout is pure presentation. There are no semicolons to place, no braces to align, and comments live only at the top of the file, never wedged between two lines the printer might want to merge. The formatter may re-lay-out freely, certain that no arrangement can change what the program means.
The grammar is small and regular.
Almost everything in EO is the same shape —
an abstraction with attributes, or an application of one object to others.
A single penalty function therefore covers the whole language,
with none of the per-construct exceptions
that bloat a clang-format configuration.
The layout space is finite and shallow. Each object is essentially either vertical or horizontal, so the number of candidate layouts for a subtree stays modest, and a recursive search can weigh them all without the combinatorial blow-up a curly-brace language would suffer.
There is a genuine appetite for one true form. The EO community already prefers a single canonical style. A penalty function turns that preference into arithmetic, and arithmetic does not hold opinions.
We are not claiming to have invented this. Treating layout as a cost to be minimized is an old and honorable idea.
The seminal work is Knuth and Plass’s line-breaking algorithm from 1981, which assigns “badness” to each way of breaking a paragraph and uses dynamic programming to find the globally optimal set of breaks; it is why TeX sets such beautiful paragraphs. The classic pretty-printers by Oppen and later Wadler chose layouts greedily instead, trading optimality for speed.
The closest relative to what we are doing is
Phillip Yelland’s A New Approach to Optimal Code Formatting (Google, 2016),
whose rfmt formatter selects the layout
that minimizes an explicit, tunable cost function —
penalizing characters past the margin and rewarding compactness —
exactly the shape of our penalty.
Jean-Philippe Bernardy’s A Pretty But Not Greedy Printer (ICFP 2017)
makes the “render everything, keep the shortest that fits” idea rigorous,
and Porncharoenwase and colleagues’
A Pretty Expressive Printer (OOPSLA 2023)
generalizes the cost into a pluggable “cost factory,”
of which our indent/bracket/overflow weights are simply one instance.
Our contribution is not the algorithm but the marriage: a strict-grammar language whose finite, semantics-free layout space lets a penalty-minimizing printer do its best work with almost no special cases. The idea is borrowed; the fit is ours.
That’s all for today. Next time your EO looks a little off, remember that somewhere the compiler is quietly adding up the damage, and choosing the layout that costs you the least.
]]>>> EO syntax stand for”?
In one of the previous releases, we introduced this EO syntax for the automated naming of abstract objects. The only place where such auto-named abstract objects are allowed is as arguments of an application. They CAN’T be used as top-level abstract objects because that wouldn’t make any sense — there would be no way to “touch” them from other objects.
[x] >> # prohibited
malloc.of
12
[m] >> # allowed
The idea is simple: generate a random unique name for an object if the user considers meaningful naming unnecessary. But why might they decide this? That’s the most interesting part.
To understand the real reason, we need to go back to the
previous blog post,
particularly the section about the ρ (Rho) attribute. Let’s recap some important points:
ρ (Rho) attribute of the object voice refers to the object animal that uses voice.ρ (Rho) attribute is indicated by the ^ sign.animal uses the object voice” implies dynamic dispatch.animal.voice.ρ (Rho) attribute is initially empty and is set right after dynamic dispatch occurs.[name] > animal
[] > voice
animal "kitty" > cat
cat.voice > meow
In the code snippet above, we copy the object animal and set its attribute name to "kitty"
(which is a string object). Then, we take the voice attribute from the object cat.
At the exact moment the object voice is retrieved, its ρ (Rho) attribute is set and starts
referring to the object cat. Now, we can do meow.^.
Considering the above, we can assume that for the object meow (which is a copied voice object)
to use the ρ (Rho) attribute, voice must be “taken” (or dispatched) from somewhere
(specifically, from the object cat). If it has to be “taken,” that means the object cat must
have an attribute named voice, because dynamic dispatch is only possible via an attribute name.
This is the key point: an object must have an attribute with a name. Only the presence of a name
allows the object to have the ρ (Rho) attribute.
Now, let’s return to the example with abstract objects.
[] > foo
"Hello" > greetings
malloc.of > @
5
[m]
$.^.greetings > str
m.write str > @
Here, we have an object foo with two attributes: greetings and @. The attribute @ is bound
to the object malloc.of, which is copied with two arguments: the object 5 and a nameless
abstract object (let’s call it “scope”). The “scope” has three attributes: m, str, and @.
As you can see, str is bound to a chain of dynamic dispatches: $.^.greetings.
Here, $ means “this” (i.e., the abstract object itself, “scope”);
.^ takes the ρ (Rho) attribute of the abstract object;
and .greetings retrieves the greetings attribute.
Clearly, “scope” is trying to access the greetings attribute of foo via its ρ (Rho) attribute.
For this to work, “scope” must have the ρ attribute referring to foo, meaning that “scope” must
be dispatched (or “taken”) from foo. However, “scope” lacks a name. No name means no dynamic
dispatch, and without dynamic dispatch, there is no ρ (Rho) attribute.
The solution is simple: give a name to “scope”.
[] > foo
"Hello" > greetings
malloc.of > @
5
[m] > scope
$.^.greetings > str
m.write str > @
This is a sugared version where the name scope is placed at a certain nesting level.
To better understand it, let’s rewrite it in its canonical form, which is semantically the
same (and which our compiler actually builds under the hood).
[] > foo
"Hello" > greetings
[m] > scope
$.^.greetings > str
m.write str > @
malloc.of > @
5
$.scope
Now, you can see that foo has one more attribute, scope, and the second argument of
malloc.of now appears slightly different: $.scope. Take a closer look at it.
What do you see? Right! This is dynamic dispatch we have here! The $ means “this”
(i.e., the current abstract object, foo), and .scope retrieves the scope attribute
from foo. This means that right after the dispatch is done, the scope object has
its ρ attribute set, referring to foo, and $.^.greetings starts working correctly.
This solves the main problem. However, the canonical form is somewhat verbose, while the sugared form relies on attribute naming when it’s unnecessary.
For cases where an abstract object’s name is unimportant but must be present to enable dynamic
dispatch, we introduced the >> syntax.
[] > foo
"Hello" > greetings
malloc.of > @
5
[m] >>
$.^.greetings > str
m.write str > @
Under the hood, the compiler rewrites it into something like this:
[] > foo
"Hello" > greetings
[m] > random-unique-name
$.^.greetings > str
m.write str > @
malloc.of > @
5
$.random-unique-name
It continues to work according to the same rules but looks cleaner for the user.
That’s all for today. Hopefully, you now have a better understanding of the ρ attribute and
dynamic dispatch in EO.
σ (Sigma) attribute. So, this blog post will try to
explain all special attributes and assets such as Δ (Delta), φ (Phi), σ (Sigma), λ (Lambda),
and ρ (Rho) as promised in one of the previous blog posts.
The first special attribute we’re observing (and which was removed) is σ (Sigma). The σ
attribute of the object X was the attribute that referred to the object Y inside which the
scope object X was born (formed or created for the first time).
The σ attribute in EO:
& sign.Φ had it.For example, int.& -> eolang, float.div.& -> float. Consider the next code snippet:
[] > loop
"Hello, world" > str
while > @
true
[i]
stdout > @
&.str
Here we have an endless while loop. The second argument of the object while is an anonymous
abstract object, let’s call it X. The X object is not used in the scope of the object loop;
it’s just created here. The object X will be used inside the scope of the object while when
dataization is started. But as you may see X has access to the scope of the object loop via
& and may reach the attributes of loop like str.
And we decided that it was a bad idea to give the object such an opportunity to have access to the
place where it was born. It kind of breaks the idea of object orientation because & is actually
a static attribute like a static method in Java. We don’t tolerate static methods and attributes,
here’s why.
The second special attribute we’re observing is ρ (Rho). The ρ attribute of the object X is
the attribute that refers to the object Y that uses the object X. In EO, the attribute ρ is
indicated by the ^ sign. Drawing the analogy with Java, the closest thing to ρ is the this
keyword which refers to the current object:
class Animal {
String type;
Animal(String tpe) {
this.type = tpe;
}
void voice() {
System.out.print("I'm a %s", this.type)
}
}
Animal cat = new Animal("Cat");
cat.voice(); // I'm a Cat
Animal dog = new Animal("Dog");
dog.voice(); // I'm a Dog
Here we create two instances of Animal - cat and dog. The this keyword inside their
voice functions refers to different objects - cat and dog accordingly.
The same functionality can be achieved in EO:
[type] > animal
[] > voice
stdout > @
sprintf
"I'm a %s"
^.type
animal "Cat" > cat
cat.voice > meow # I'm a Cat
animal "Dog" > dog
dog.voice > woof # I'm a Dog
The main difference between this in Java and ρ in EO is the moment when these “links” actually
become referred to the objects. In Java - right after the object is created, in EO - on attribute
dispatch. Let’s look a bit closer. The dynamic dispatch in EO is a mechanism of retrieving an
attribute from the object. Syntactically it’s implemented via “dot-notation”.
So this is dispatch:
cat.voice
We’re trying to retrieve an attribute voice from the concrete object cat. At the moment we’ve
found the attribute voice inside the object cat and are ready to return it - the voice attribute
is copied and its ρ attribute is initialized with a link to the object cat. Until we touch
the cat.voice object, its ρ attribute refers to Ø (nothing).
A few more examples:
cat.voice > voice1 # voice1.^ -> cat
cat.voice > voice2 # voice2.^ -> cat
dog.voice > voice3 # voice3.^ -> dog
cat.voice > voice4 # voice4.& -> animal - deprecated
dog.voice > voice5 # voice5.& -> animal - deprecated
The third special attribute we’re observing is φ (Phi). We’ve already described the attribute in
one of the previous blog posts, but let’s dive a bit deeper. In EO, the attribute is indicated
by @ sign. The attribute is not mandatory and may be absent. The φ attribute of the object X
is the attribute that refers to the object Y which object X decorates. The main purpose of
decoration is the reuse of attributes. For example:
[type] > animal
[] > voice
stdout > @
sprintf
"I'm a %s"
^.type
[] > cat
animal "Cat" > @
Here we have an object cat which decorates an object animal with type attribute set to
"Cat". That means that all the attributes which are allowed to be taken from the object animal,
like voice, are allowed to be taken from the object cat:
cat.voice > meow # I'm a Cat
The decoration may have several layers and all the attributes on the deepest level are available on the top level:
[type] > animal
[] > voice
stdout > @
sprintf
"I'm a %s"
^.type
[color] > cat
animal > @
sprintf
"%s cat"
color
[] > black-cat
cat "black" > @
Here the object black-cat decorates the object cat and the object cat decorates the object
animal. This onion of decorators allows taking the attribute voice from the object black-cat:
black-cat.voice > meow # I'm a black cat
The fourth special thing we’re observing is Δ (Delta) asset. A few words about this asset:
org.eolang.bytes object has this asset.The last special thing we’re observing is λ (Lambda) asset. Let’s look at it a bit closely:
λ asset are called “atoms”.φ attribute.λ asset, as well as the φ attribute, also allows reusing the attributes:[] > mars-temperature /float # measures the temperature on Mars and returns float
mars-temperature.div 10 > divided
Here, as you may see, mars-temperature is the atom that does not have an attribute div and
returns float. However, we can still retrieve the attribute div from it. It will go to the
λ asset, execute it, do some calculations, return us some float, and the div attribute will
be taken from this float.
That’s all for today. We’ll be right back in a week with a new fresh blog post. Stay in touch.
]]>