Why We Chose S-Expressions for Axon

When designing a new systems language, the safe bet is to adopt a C-like syntax. It’s what developers know. It’s what powers Rust, Go, Zig, and Swift.

So why did Axon, a language targeting absolute maximum performance and safety, adopt S-expressions?

The Parsing Problem

To understand the decision, you have to understand how Large Language Models generate code: one token at a time.

When an LLM generates C++ or Rust, it is walking a tightrope. It must balance business logic with intricate rules of operator precedence, semicolon placement, and matched braces. A single misplaced token causes a cascading parser failure.

For an LLM, C-like syntax is “lossy.” The visual representation of the code does not map directly to the Abstract Syntax Tree (AST). The LLM has to implicitly learn the parsing rules of the language.

Homoiconicity to the Rescue

S-expressions are homoiconic. This means the code is the data structure.

Consider a simple math operation in C:

int result = 2 + 3 * 4;

To understand this, the parser (and the LLM) must know that * has higher precedence than +.

In Axon:

(let result (+ 2 (* 3 4)))

There is zero ambiguity. The parentheses explicitly define the AST.

For an LLM, generating S-expressions is incredibly robust. It completely eliminates a massive class of syntax errors, allowing the AI to focus its “attention” entirely on solving the problem, rather than fighting the parser.

The Token Economy

Our benchmarks show that generating equivalent logic in Axon requires roughly 40% fewer LLM tokens than Rust. In an era where context windows and token generation speeds are premium commodities, this efficiency is a massive competitive advantage.

By choosing S-expressions, we built a language that AI models can master instantly.