Synth-OOP: An Object-Oriented Language Where Operators Become Methods

Abstract

Synth-OOP is an experimental object-oriented programming language that I designed and implemented from scratch. Syclun is currently its reference interpreter.

The most direct—but not core—feature of the language is that traditional operators are not treated as an independent core mechanism. Instead, operations are represented uniformly as method calls on objects. Thus, the computation expressed by a + b corresponds to something like a.+(b) in Synth-OOP. Stream operations, object behavior, and runtime method dispatch follow the same object model.

This design is not intended simply to create syntax that looks unusual. My main goal is to investigate one question:

If as many language operations as possible are reduced to object behavior, can operators, methods, streams, closures, and runtime mutation share the same runtime mechanisms?

Around this idea, I implemented a Lexer, recursive-descent Parser, Runtime Object Model, Frames, closure environments, method signature checking, an exception system, and self-registering Native Libraries. Syclun currently uses a tree-walking interpreter as its reference execution engine, with plans to introduce IR, hot-path detection, and JIT compilation later.

This article is not intended to prove that the current Synth-OOP is better than C++ or other mature languages. Instead, I am more interested in whether this design can form a internally consistent language model, and what it actually costs to implement such a model in a real runtime.

From the perspective of language philosophy and computer science, of course, the execution speed of the language could theoretically approach—and perhaps even surpass—C++ at some point. But that is a problem for later.

The current implementation can already run basic programs, standard-library calls, and practical examples including weighted shortest-path algorithms. At the same time, features such as dynamic object mutation, duck typing, and interpretation have exposed problems that a future JIT implementation will need to address.

In other words, this project is currently closer to a new experimental language with a running implementation than to a finished industrial compiler.

1. Operators Are Object Behavior

Most programming languages treat a + b as a special language construct. Even if a compiler eventually lowers it into a function call or machine instruction, + still has a special status at the language level. Operators such as +, -, *, /, ==, <, and > all have their own syntax and semantics.

Synth-OOP takes a different approach.

The basic assumption is:

If “addition” between two objects ultimately means finding some behavior and executing it, there is no fundamental reason for addition to remain a completely special mechanism at the language level.

Therefore, a + b can be expressed as a.+(b). Here, + is no longer a special Operator Token. It is simply a name.

This looks like a syntactic change, but it affects the implementation much further. Once + is an ordinary method, obj.foo(x) and a.+(b) can share the same method lookup and invocation mechanisms at the Runtime level.

The question therefore changes from:

“How many special operators does the language need?”

to:

“What behaviors do objects need to provide?”

This became the starting point for the rest of Synth-OOP's object model.

2. Design Principles: Push Language Mechanisms Toward Runtime Objects

The design choices in Synth-OOP are closely related. I tend to describe them using three principles.

Principle 1: Operations Are Behaviors

+, -, and similar operations ultimately become object methods.

Principle 2: Objects Are Runtime Entities

A variable name is not the data itself. It is an entry point for accessing an object.

Principle 3: Behavior Is Also a Runtime Entity

Methods can be looked up and invoked, and under certain conditions they can also be rebound at runtime.

These three ideas form the relationship:

data → object → behavior → method dispatch

rather than treating variables, operators, functions, and classes as several unrelated language mechanisms.

This is why I eventually realized that the most interesting part of Synth-OOP is not really “having no operators”. The more interesting question is:

If operators disappear, can many other things in the language become unified as well?

3. From Language Design to the Lexer: Why the Lexer Should Be as “Dumb” as Possible

This design first affects lexical analysis.

Syclun's Lexer is located at /src/lexer.hpp. It currently distinguishes:

<number>
<string>
<name>
<symbol>
<eof>

There is one particularly deliberate choice here:

The Lexer does not recognize traditional keywords.

For example, true, false, if_, and void are all <name>. Even ->, ~>, and => are treated as names.

! is also a valid name character, so things such as std::Number! and @!get can be represented as complete names.

Only things such as <<, >>, (, ), [, ], {, }, ,, ;, ., $, &, @, and # enter <symbol>.

The theoretical motivation is simple:

If the language wants symbols to participate in method names, the Lexer should not interpret those symbols as language operations ahead of time.

For example, for a.+(b), the Lexer does not need to understand “this is an addition”.

It only needs to produce:

name("a")
symbol(".")
name("+")
symbol("(")
name("b")
symbol(")")

Therefore, + has no fundamental lexical difference from any other method name.

This does not mean that the Lexer is more sophisticated. Quite the opposite: it becomes deliberately dumber.

But this kind of “dumbness” is useful:

Semantic decisions are postponed until the stage where semantics actually belong.

4. Parser: Compressing Syntax Differences into the AST

The Parser is located at /src/parser.hpp and uses a conventional recursive-descent implementation.

The current structure of a behavior node is roughly:

behavior = [sign, block]

sign = {
    value = pattern,
    kids = [arguments, output]
}

The important part here is not recursive descent itself. Recursive descent is merely the implementation technique.

What really matters is:

No matter what the source syntax eventually looks like, the Interpreter should see a stable AST structure.

This decouples the Lexer / Parser from the execution backend.

The current execution path is:

source → Lexer → Parser → AST → Interpreter

If a JIT is introduced later, it can become:

source → Lexer → Parser → AST → IR

and then the IR can be consumed by either the Interpreter or JIT → Native Code.

So using recursive descent today does not create a structural obstacle for a future JIT.

5. Runtime Object: What Does a “Living Object” Actually Mean?

Saying that “objects are alive” does not mean much if it is only used as a slogan.

So I would rather look directly at the fields in the Runtime.

runtime.hpp and builtin.hpp are responsible for this part.

The Runtime uses a prototype / instance organization. ClsProto stores prototype-level information, including default attributes, a method table, constant members, and an optional on_release hook.

RuntimeClass represents an actual runtime instance.

Instances copy members from their prototypes, which prevents different instances from sharing the same mutable state.

Several fields are particularly interesting.

const_state

This corresponds to the object's obj.#() operation.

It is a one-way transition:

normal → frozen

There is no reverse frozen → normal operation.

private_attrs

Private attributes are not simply hard-coded into a static type definition. They can be added to an object at runtime.

For example:

obj:-(Type v) << value

They can only be accessed when the object's own behavior is running under the condition:

self == this

const_attrs

Constant members defined in the class body are stored here.

The interpreter rejects paths that attempt to write to these members.

methods_dirty

When the method table is modified at runtime, this state is marked.

Its current role is simple, but it also provides a natural observation point for future dynamic optimization.

6. Why Dynamic Method Mutation Directly Affects JIT

Consider:

obj.foo(x)

If foo never changes, a compiler can easily optimize the call to a fixed target.

But Synth-OOP allows methods to be modified at runtime.

The first time the call happens, obj.foo might point to A.

Later, it might become:

obj.foo → B

This means a JIT cannot simply assume that:

foo == A

forever, unless it can also verify that the object layout, method table, and signature remain unchanged.

A reasonable future implementation path would therefore be:

first call → record object / method layout → establish inline cache → fast path → detect state change → invalidate → return to generic dispatch

If the JIT makes more aggressive assumptions about runtime state, it may additionally need:

speculative optimization
deoptimization

In other words:

Runtime state that looks unrelated to performance today may actually be one of the key inputs determining whether a future JIT can work.

I think this is one of the places where Synth-OOP's language design and execution-engine design are most tightly connected.

7. Interpreter: Turn Semantics into Something Observable First

Syclun currently uses a tree-walking interpreter.

The source is located at:

src/interpreter.hpp

Every behavior invocation creates a Frame.

A Frame at least needs to handle:

local variables
parent environment
self

So a method call roughly goes through:

AST node → evaluate arguments → create Frame → resolve object → look up method → check signature → execute behavior → return

This is obviously not a high-performance execution model.

If the same call is executed one million times, the interpreter participates in all one million executions.

But at the current stage, this cost is acceptable.

The reason is:

The primary question at this stage is not “How fast does the machine execute?” but “Is the language semantics sufficiently well defined?”

If the interpreter cannot become a reliable semantic reference, compiling directly to machine code would only hide errors more deeply.

8. Closures: Why They Can Also Fit the Same Object Model

Closures are often implemented as a special kind of function object.

But from a runtime perspective, a closure can be decomposed into:

code + captured environment

For example:

f = {
    code = A,
    env = {
        x = ...
    }
}

The environment can then be connected to the current Frame when the closure is invoked.

This has similarities to closure conversion / defunctionalization in compiler theory.

I am not claiming that the current Syclun source code strictly implements a textbook “defunctionalized intermediate language”.

A more accurate statement is:

The existing Frame, environment objects, and unified invocation entry point make this kind of unification natural.

This means that ordinary behaviors, member methods, and closures do not necessarily need to become three completely independent invocation mechanisms.

From a design perspective, this is the same direction as “operators are methods”:

Try to minimize special cases in the language runtime.

9. Duck Typing: From “What Are You?” to “What Can You Do?”

Synth-OOP's duck typing also follows from the same object model.

Suppose a call only requires an object to provide:

:=

Then what it really needs to know is:

“Does this object have :=?”

rather than:

“Is this object an IOStream?”

Compatibility therefore moves from nominal typing:

A implements X

toward behavior:

A has method X

This does not mean that checking is abandoned entirely.

Syclun also has:

g_sign_enforcer

which is responsible for signature constraints at method-call boundaries.

So the more precise description is:

Nominal type identity is not required, but the required behavior must exist, and its signature must be compatible.

Duck typing is therefore not the removal of type constraints. It changes what those constraints care about.

It asks:

“Can you perform this operation?”

rather than:

“Which type name do you belong to?”

10. Stream Operations: Syntax That Looks Like C++, but Is Not C++

Consider:

io::out << "Hello World!";

At a glance, it looks a lot like:

std::cout << "Hello World!";

But the semantics are different.

Synth-OOP defines:

a << b

as a flow relationship:

first publish b → call b's =: → let a receive it → call a's :=

Therefore:

a << b

can be understood as:

flow b into a.

This means stream operations do not need to become an isolated I/O mechanism.

They still follow the same main path:

object → method → method dispatch

This is another core design goal of Synth-OOP:

If two language constructs ultimately express object behavior, they should share the same runtime mechanism whenever possible.

11. A Complete Example: Weighted Shortest Path

Showing only Hello World would make it difficult to demonstrate whether the language design has any practical value.

So here is a slightly more complete example:

&io;
&structs;

$Program {
  @::[{
    -(structs::Graph g);

    g.add_edge(1, 2, 1);
    g.add_edge(1, 3, 2);
    g.add_edge(2, 4, 1);
    g.add_edge(3, 4, 7);

    -(std::Array p) << g.shortest_path(
      -(std::Number n) << 1,
      -(std::Number n) << 4
    );

    io::out.push_line(p);
    io::out.push_line(
      g.shortest_distance(1, 4)
    );
  }];
};

Here we construct a graph where 1 → 2 has weight 1, 2 → 4 has weight 1, while another branch is 1 → 3 with weight 2, followed by 3 → 4 with weight 7.

Therefore, from 1 to 4:

1 → 2 → 4

has a total weight of 3.

The expected output is:

[1, 2, 4]
3

This example has an important implication:

The algorithm itself is not the language innovation.

Dijkstra's algorithm has been around for a long time.

What is actually worth observing is the boundary between the language and the standard library.

Synth-OOP is responsible for objects, behaviors, invocation, and data organization.

structs is responsible for Graph, Dijkstra, and the underlying data structures.

Therefore, the language does not need to reinvent a:

priority_queue

nor does it need to implement the entire shortest-path algorithm directly in the example just to prove that the language is “Turing complete”.

This is also my basic view of standard-library layering:

The language should provide expressive power; the standard library should provide mature engineering capabilities.

12. A Real Implementation Bug: BFS Was Once Used as Shortest Path

This actually says more about the engineering state of the project than a successful Hello World program does.

The early implementation of Graph.shortest_path used BFS.

The problem is:

BFS minimizes the number of edges, not the total edge weight.

For example, 1 → 4 contains only one edge, while 1 → 2 → 4 contains two.

If the weights are:

1 → 4 = 100
1 → 2 = 1
2 → 4 = 1

then the actual shortest path should be:

1 → 2 → 4

But BFS tends toward:

1 → 4

because it only considers the number of layers.

This bug is particularly interesting because the program does not crash, the interpreter does not report an error, and the type checker does not report an error.

Even a very simple test could pass.

The problem was eventually found by an assertion in a regression test.

The implementation was then changed to Dijkstra, and:

shortest_distance

was added.

This example made me realize that the engineering quality of a language implementation cannot be judged only by whether:

Lexer
Parser
Hello World

work.

We also need to ask:

Does the standard library actually implement the semantics it claims to provide?

This is why testing is just as important as language design itself.

13. Native Libraries: How Capabilities Outside the Language Enter the Language

Syclun currently has standard libraries including:

io
system
maths
async
hash
structs
re
assert
sugar
http
internet
bt
gui
windows

These standard libraries are integrated through a self-registration mechanism.

For example:

inline bool _registered =
    (rt_builtin::register_native_lib(
        "io",
        &init_io_stdlib
    ), true);

This solves a very specific problem:

The Interpreter should not need to know how many standard libraries exist.

The library registers itself:

library → registration → Runtime

Instead of having the interpreter contain something like:

Interpreter
    → if io
    → if maths
    → if structs
    → ...

This creates a relatively clear boundary between the language core and host capabilities.

That boundary is also important for a future JIT.

Ultimately, generated machine code still needs to call capabilities provided by:

C++
Runtime
OS

So native builtins are not merely a leftover from the interpreter era. They will remain part of the execution system in the JIT era as well.

14. Why I Am Not Rushing to Build a JIT

From a technical perspective, a language could simply go:

Lexer → Parser → LLVM → Native Code

But I did not choose that route.

The reason is not that LLVM is inadequate.

It is that the language semantics are still changing.

If the Runtime object model is A today and B tomorrow, the AOT / JIT backend, IR, optimizer, and code generator may all need to change with it.

By contrast, a tree-walking interpreter can serve as:

the reference semantic implementation.

Therefore, the current development order is:

define semantics → implement Runtime → write tests → make the interpreter the reference → design IR → build JIT

From this perspective:

The current low performance is not because the project has ignored compilation. It is because semantic correctness and execution performance are intentionally being handled in separate stages.

15. Error Handling Is Also Part of Language Implementation

Syclun's error system uses a diagnostic format somewhat similar to g++:

Type
Location
Message

It then attaches:

source location
caret
execution stack
line number

For example:

some bad code here
             ^~~~

UTF-8 is also considered explicitly.

The reason is simple: if the source contains Chinese text such as:

这是一个错误

the error pointer should not become corrupted simply because a byte offset was used incorrectly.

The interpreter can be slow.

But:

Error messages must be as accurate as possible.

At the current stage, one practical advantage of the tree-walking interpreter is that information such as:

source location → AST → behavior → Frame

is still available.

If execution eventually becomes native machine code, additional debug metadata will be required to map machine addresses back to source locations.

So making the error system robust now is not merely “polishing the output”.

It is also preserving semantic information that future execution engines will need.

16. Current Implementation Boundaries

To avoid presenting an experimental project as if it had already solved everything, here are the current limitations.

Performance

The current implementation is a tree-walking interpreter, so execution efficiency is not a design goal yet.

JIT

Not implemented yet.

IR, hot-path detection, inline caches, and deoptimization are all future work.

#Contract

The current implementation mainly covers compile-time expression of contracts. Parameter-level constraints are not fully implemented yet.

Recursion

Currently:

RECURSION_LIMIT = 1000

A relatively large C++ stack is used to provide additional room for legitimate deep recursion.

Cross-platform Support

The core can be compiled across platforms, but capabilities such as:

gui
windows
bt

still depend on the specific runtime environment.

Syntax Stability

Before 1.0.0, there is still room to adjust both syntax and semantics.

So this is currently a good stage for design suggestions.

17. Where Is the Actual Contribution?

If this project is understood simply as:

“Yet another scripting language.”

then there is indeed nothing particularly special about it.

What makes me want to continue working on it is that the following chain has now largely been connected:

language syntax → AST → Runtime Object → Frame → method dispatch → closures → Native Library → error system

Some of these designs even constrain each other.

For example:

operator → method

naturally requires:

unified method dispatch

which naturally requires:

Runtime Object

and a dynamic Runtime Object then requires:

method-change detection

which directly affects:

JIT
Inline Cache
Deoptimization

If closures also enter the same object / Frame model, then:

functions
methods
closures

can share more runtime infrastructure as well.

So I now prefer to think of Synth-OOP as:

an experiment in language design that starts at surface syntax and goes all the way down to the runtime execution model.

18. From Here On, the Really Difficult Part Begins

Currently:

source → AST → Interpreter

already works.

The next stage is:

AST → IR → Interpreter / JIT

The difficult questions will gradually change from:

“What does this code mean?”

to:

“What stable assumptions can this code actually make at runtime?”

In particular:

dynamic objects
dynamic methods
method signatures
closure environments
Native Calls

all matter.

For example, can:

obj.foo(x)

actually be optimized?

It is not enough to look at the string:

foo

We also need to know:

What object is obj right now?
Has the method table changed?
Is the signature stable?
What objects has this call site seen before?

Therefore, the real performance work in Synth-OOP is probably not:

“Compile + faster.”

It is:

How do we turn a dynamic object model into runtime assumptions that a JIT can reliably exploit?

That is, in my opinion, the part of this project most worth continuing to research as it moves from a “language toy” toward a language implementation experiment.

19. Conclusion: This Is Not a Finished Product, but It Is Already a Complete Experiment

Of course, a language written by one person is going to have plenty of imperfections.

Synth-OOP is still very far from being a mature industrial language.

But at this point, I can at least move it from:

“I have a weird language idea.”

to:

“That idea now has a Lexer, Parser, Runtime, Interpreter, standard library, tests, and real programs.”

There is actually a lot of distance between those two statements.

A language starts becoming interesting not when you invent:

a.+(b)

but when you have to answer questions like:

• What exactly is this +?
• Where is it looked up?
• How is it invoked?
• How are parameters checked?
• How is a Frame created?
• How are closures captured?
• How can objects change?
• How are errors located?
• How are Native Libraries integrated?
• How will the JIT know whether something has changed?

What I am doing now is essentially turning these questions into code one by one.

For now:

“It can interpret.”

Next:

“It needs to compile.”

And after that:

“It needs to compile the things worth optimizing intelligently, even under a dynamic object model.”

As for whether I will ultimately succeed, I do not want to give a conclusion yet.

Because with language implementation:

Code is more honest than slogans.

First, make 1.0.0 solid.

Then keep going.

Repository

github.com/VP-xudon/Syclun

The wiki contains more complete documentation on the syntax and standard library.

If you want to try it yourself, the simplest way is:

bash build.sh
./build/synth examples/hello.syn

Then you can explore:

examples/
src/lexer.hpp
src/parser.hpp
src/runtime.hpp
src/interpreter.hpp

Issues, syntax suggestions, bug reports, and standard-library contributions are welcome.

After writing this much, I still hold the same view:

A language written by one person is bound to have things that were not considered carefully enough.

So please be gentle. qwq