DEV Community: Kausalya S

I thought porting TinyExpr to Rust would be easy. Then the tests started disagreeing.

Kausalya S — Thu, 13 Aug 2026 06:07:15 +0000

I’m sharing this to show how I resurrected TinyExpr in Rust, proved behavioral equivalence, and learned from the edge cases that broke along the way.

I ported TinyExpr, a tiny C mathematical expression parser, to Rust.

At first, the project looked deceptively simple.

Tokenize an expression.

Parse it.

Build an AST.

Evaluate it.

Done.

Except it wasn't.

The difficult part wasn't getting:

2 + 3 * 4

to return:

The difficult part was answering a much more important question:

How do you know a port is actually faithful to the original implementation?

That question turned a small parser rewrite into a deep investigation of grammar, operator associativity, floating-point behavior, error handling, optimization, variables, combinatorics, and edge cases.

This is the story of my TinyExpr → Rust port for Code Resurrection 2026.

The project

The original TinyExpr is a lightweight C expression parser and evaluator.

It can evaluate expressions like:

2 + 3 * 4
sqrt(100)
pow(2, 10)
sin(pi / 2)
x * y + 5

The original implementation is small, but it packs a surprising amount of behavior into that small codebase.

My goal wasn't to rewrite it line by line.

I wanted to preserve its observable behavior while redesigning the implementation around Rust's type system.

The architecture became:

Expression
    │
    ▼
  Lexer
    │
    ▼
  Parser
    │
    ▼
   AST
    │
    ▼
Optimizer
    │
    ▼
 Evaluator
    │
    ▼
  Result

The Rust implementation uses:

enums instead of tagged integer flags
Result instead of C-style error handling
ownership instead of manual memory management
HashMap for variables
a typed AST
recursive-descent parsing
constant-folding optimization
zero unsafe Rust

The code was cleaner.

But clean code isn't proof of compatibility.

The first mistake: assuming the math was the hard part

My first instinct was to test obvious expressions:

1 + 2
2 * 3
sqrt(16)
sin(pi / 2)
pow(2, 10)

Everything worked.

That created a dangerous illusion.

A parser can pass every "normal" test while still being behaviorally different from its predecessor.

For a port, these are not enough:

2 + 3

and:

sqrt(16)

I needed to test the weird stuff.

So I started treating the original TinyExpr behavior as a specification.

The test suite became the specification

Instead of asking:

"Does my Rust implementation look correct?"

I asked:

"Does my Rust implementation behave like TinyExpr?"

That changed how I wrote the tests.

I built coverage around several categories:

Arithmetic

1
2+1
3*2*4
3-2-4
3/2/4

Precedence

100^.5+1
sqrt 100 * 7

Unary operators

-.5
--.5
---.5

Functions

sin
cos
sqrt
pow
atan2
log
ln

Variables

x+x+x-y
x*y^3
cos x + sin y

Sequences

1,2
1,2,3
(1,2),3

Invalid expressions

1+
(1
1**1
a+5

Numerical edge cases

0/0
1/0
fac(-1)
ncr(2,4)

And then I added optimization tests.

Because parsing the right expression isn't enough.

The optimizer has to preserve the same result too.

Then I found the first important difference

One of the most interesting compatibility issues was floating-point constants.

The original test expectations used values such as:

3.14159

while Rust's f64::consts::PI evaluates to:

3.141592653589793

Mathematically, both represent π to different precisions.

But a compatibility test doesn't care about what should happen mathematically.

It cares about what the implementation actually produces.

My first test failed with:

expected 3.14159,
got 3.141592653589793

The difference was:

0.000002653589793...

That forced me to revisit the testing strategy.

The lesson was simple:

A compatibility test must distinguish between an intentional numerical difference and an actual semantic difference.

I adjusted the comparison to use a floating-point tolerance rather than requiring exact equality.

That also fixed the corresponding optimization test for:

pi * 2

The six-hour problem wasn't actually six hours

One of the biggest challenges wasn't a single compiler error.

It was figuring out which behavior belonged to the original implementation and which behavior was an artifact of my Rust design.

TinyExpr has some particularly interesting semantics around:

and unary operators.

For example:

2^3^4

isn't universally interpreted the same way by every expression language.

This implementation follows the original/default TinyExpr behavior:

(2^3)^4

rather than:

2^(3^4)

That means operator associativity isn't just a parser implementation detail.

It's part of the API.

The same applies to expressions such as:

-2^2

and:

-2^-3^-4

A "cleaner" grammar isn't necessarily a compatible grammar.

That became one of the central principles of the project:

When porting software, don't silently fix semantics that users may depend on.

The edge cases became the real specification

Some of the most useful tests were the ones that looked ridiculous.

For example:

100^--.5+1

and:

100^---+-++---++-+-.5+1

These aren't expressions anyone should casually write.

But that's exactly why they're valuable.

A normal application test tells you whether the implementation works for normal usage.

A compatibility test tells you where the implementation's boundaries actually are.

And those boundaries are often where ports break.

Scientific notation exposed a limitation

Another interesting discovery was scientific notation.

The original TinyExpr test suite contains expressions using values such as:

1e3

But the Rust lexer in this implementation currently recognizes numeric literals using digits and . without exponent notation.

So:

1e3

doesn't become:

Instead, it gets tokenized differently and ultimately fails.

Rather than hiding that difference, I made it an explicit test:

#[test]
fn scientific_notation_is_not_supported() {
    assert!(interp("1e3").is_err());
    assert!(interp("5e-5").is_err());
    assert!(interp("1.0e3").is_err());
}

That distinction matters.

There is a huge difference between:

"I forgot to test this."

and:

"This behavior isn't supported, and I have a test documenting it."

The second is an engineering decision.

Then combinatorics got interesting

TinyExpr includes:

fac()
ncr()
npr()

for factorials, combinations, and permutations.

These exposed another subtle difference.

The original C implementation performs integer-style operations and has overflow behavior that occurs much earlier than an IEEE-754 f64 would naturally overflow.

The Rust implementation uses f64 directly.

So something like:

ncr(300,100)

can remain finite in Rust even though the original implementation treats the corresponding integer calculation as overflowing.

That meant I couldn't simply write:

assert!(value.is_infinite());

for every upstream overflow case.

I had to distinguish:

original integer overflow

from:

actual f64 overflow

That resulted in separate tests documenting the divergence.

This is one of the places where I decided that being explicit about a behavioral difference was better than pretending the implementations were identical.

Optimization had to be tested independently

The project also includes constant folding.

For example:

5 + 5

can become:

before evaluation.

Likewise:

pow(2,2)

can become:

The optimizer therefore has its own correctness requirement.

I tested that a constant expression becomes an AST number directly:

5 + 5
      ↓
   Number(10)

But I also tested something more important:

Does optimized evaluation agree with normal evaluation?

Because an optimizer that produces the wrong answer faster is still wrong.

Variables gave me another compatibility problem

Variables look simple:

x * y

But variable behavior is part of the language semantics.

I tested expressions against changing environments:

x = 0, y = 2
x = 1, y = 2
x = 2, y = 2
...

and checked expressions such as:

cos x + sin y
x+x+x-y
x*y^3

I also tested unknown identifiers.

For example:

xx*y^3

can parse successfully as an identifier and then fail during evaluation because xx isn't bound.

That's different from a parser-level syntax error.

Again:

Parsing and evaluation are separate stages, and the tests need to know which stage is responsible for the failure.

The test results

After the implementation and fixes, the project reached:

30 passed

for the library's unit tests.

The smoke/conformance suite reached:

13 passed
2 ignored
0 failed

The two ignored tests correspond to functionality that the current Rust API doesn't implement yet:

custom user-defined functions
closures

I deliberately left those as ignored tests rather than pretending the feature exists.

That's important because an ignored test isn't a failure.

It's a documented boundary.

Why I didn't just delete the unsupported tests

This was a deliberate decision.

The original TinyExpr supports registering custom functions and closures.

My Rust port currently has a closed set of built-in functions.

So instead of deleting the corresponding coverage, I left explicit ignored tests explaining:

this feature exists upstream
this port doesn't implement it yet
this test should become active when the API exists

That gives future development a target.

It also makes the limitation visible.

The benchmark isn't the proof

I also added Criterion benchmarks.

They measure common expression workloads such as:

arithmetic
nested expressions
function evaluation
variable lookup
expression trees

It's tempting to make performance the headline.

But that's not what mattered most.

A fast parser that changes the semantics of:

2^3^4

isn't a successful compatibility port.

The priority was:

Correctness
    ↓
Behavioral compatibility
    ↓
Test coverage
    ↓
Optimization
    ↓
Performance

Not the other way around.

The architecture is where Rust made the biggest difference

The original implementation is C.

That means concepts such as:

memory ownership
raw pointers
manual cleanup
error codes
tagged structures

have to be handled explicitly.

In Rust, I could redesign these around the type system.

TinyExpr C	TinyExpr Rust
`malloc/free`	Ownership + `Drop`
Raw pointers	References / owned values
`NULL`	`Option`
Error codes	`Result`
Tagged structures	Enums
Manual cleanup	Automatic cleanup

The result isn't simply "the same C code written with Rust syntax."

It's a Rust implementation of the same language behavior.

That distinction matters.

What I would do differently

If I started this project again, I would change one major thing.

I would build the compatibility tests first.

My first instinct was:

Port code
↓
Make it compile
↓
Write tests
↓
Fix failures

I now think the better order is:

Study original behavior
        ↓
Build compatibility tests
        ↓
Port architecture
        ↓
Run tests
        ↓
Investigate divergences
        ↓
Optimize

Because when you're porting software, the biggest danger isn't a compiler error.

It's an implementation that compiles, looks reasonable, and is subtly wrong.

What I learned from TinyExpr

The biggest lesson wasn't about Rust.

It was about software archaeology.

When you resurrect an old project, you aren't simply translating code.

You're reconstructing intent.

You have to ask:

What behavior is intentional?
What behavior is accidental?
What behavior is part of the public API?
What edge cases did the original authors implicitly support?
Which differences are acceptable in the new implementation?
Which differences would break compatibility?

And sometimes the answer isn't obvious from the source.

The tests become historical evidence.

The parser becomes a specification.

The strange edge cases become documentation.

And failures become clues.

The most important distinction: port vs rewrite

This project taught me that there are two very different goals:

Rewrite

"How would I design this library today?"

Port

"How do I preserve what this library already means?"

Those goals can produce completely different implementations.

For TinyExpr, I chose the second.

I wanted the internals to be idiomatic Rust.

But I wanted the language semantics to remain recognizably TinyExpr.

That's why I preserved things like:

left-associative power
unary operator behavior
sequence expressions
built-in functions
variable evaluation

while changing the underlying architecture.

The impact of a tiny project

TinyExpr isn't a massive framework.

That's exactly why I liked it for Code Resurrection.

It demonstrates something important:

Software doesn't have to be huge to be worth preserving.

A small parser can sit underneath calculators, configuration systems, scientific tools, games, simulations, embedded applications, and countless internal utilities.

Preserving a tiny piece of software is also an exercise in preserving the assumptions built around it.

The code may be old.

The behavior may not be.

The final result

I started with a C expression evaluator.

I ended with a Rust implementation containing:

a lexer
recursive-descent parser
typed AST
evaluator
optimizer
built-in mathematical functions
variable support
structured errors
compatibility tests
smoke tests
examples
Criterion benchmarks
zero unsafe Rust

And more importantly, I ended with a much better understanding of what it actually means to port software faithfully.

The hardest bugs weren't syntax errors.

They were assumptions.

The lesson I'll take into my next port

If I had to reduce the entire project to one sentence, it would be this:

Don't prove that your new implementation works. Prove that it still means the same thing.

That's a much harder problem.

But it's also a much more interesting one.

And that's what made resurrecting TinyExpr worth doing.

Built for Code Resurrection 2026

This project was built as part of Code Resurrection 2026, with the goal of taking an existing piece of software and giving it a modern implementation without losing the behavior that made the original useful.

Project: tinyexpr-rs

Original project: TinyExpr

Port: C → Rust

Focus: behavioral compatibility, safety, maintainability, testing, and performance

The project is not perfect—and that's intentional.

The remaining limitations are documented rather than hidden.

Because in a resurrection project, knowing what you haven't reproduced yet is just as important as knowing what you have.

One final thought

The most surprising thing about this project was how little of the work was actually typing Rust.

The real work was asking:

"What does this tiny piece of C actually promise?"

Then writing enough evidence to defend the answer.

That's the part of software resurrection I didn't expect to enjoy as much as I did.

And it's probably the part I'll remember longest.

Kausalya-s673 / tinyexpr-rs

Idiomatic Rust port of TinyExpr with recursive-descent parsing, AST optimization, benchmarking and full test suite.

tinyexpr-rs

A safe, idiomatic Rust port of the original TinyExpr mathematical expression parser and evaluator.

Built as part of Code Resurrection 2026, this project preserves the grammar and behavior of the original C implementation while redesigning the internals to leverage Rust's ownership model, type system, and modern error handling.

Overview

TinyExpr is a lightweight recursive-descent parser capable of parsing and evaluating mathematical expressions such as

2 + 3 * 4
sqrt(16)
pow(2, 10)
sin(pi / 2)
fac(5)
ncr(5,2)

This project reimplements TinyExpr in Rust while preserving the original parser grammar and evaluation semantics wherever practical.

Unlike a direct line-by-line translation, the implementation embraces idiomatic Rust design using enums, pattern matching, ownership, and Result-based error handling.

Features

Recursive-descent parser
Expression evaluation
Constant folding optimization
Built-in mathematical functions
Variables
Built-in constants (pi, e)
Comprehensive unit and integration tests
Smoke test suite based on the original TinyExpr tests
…

View on GitHub

Resurrecting TinyExpr in Rust: What a Hackathon Taught Me About Proving a Port Works

Kausalya S — Sun, 09 Aug 2026 19:47:00 +0000

What if “modernizing” legacy software didn't mean rewriting it and hoping nothing breaks?

What if we could take a small, battle-tested C library, rebuild it in a modern language, and prove that the new implementation still behaves like the original?

That was the challenge I took on during Code Resurrection 2026.

Our project: TinyExpr → tinyexpr-rs, a safe, idiomatic Rust port of the original TinyExpr mathematical expression parser and evaluator.

And the surprising part?

The hardest part wasn't writing the parser.

It was proving that we hadn't accidentally changed what the parser meant.

The Problem: Legacy Code Still Has Value

TinyExpr is a lightweight mathematical expression engine.

Give it an expression like:

2 + 3 * 4

and it evaluates it to:

It supports much more than basic arithmetic:

sqrt(16)
sin(pi / 2)
pow(2, 10)
x*x + y*y

The original implementation is written in C.

For Code Resurrection, instead of simply translating the C code line by line, I wanted to answer a more interesting question:

Can we resurrect the functionality while redesigning the implementation around modern Rust principles?

That meant moving from C's manual memory management and raw-pointer-oriented design toward:

Rust ownership
enums
pattern matching
Result-based error handling
strongly typed AST structures
safe evaluation
zero unsafe Rust

The goal wasn't just a rewrite.

It was a behavior-preserving reimplementation.

From C to Rust

The architecture became a clean pipeline:

Expression
    ↓
Lexer
    ↓
Parser
    ↓
AST
    ↓
Optimizer
    ↓
Evaluator
    ↓
Result

The lexer converts the input into tokens.

The recursive-descent parser converts those tokens into an Abstract Syntax Tree.

The optimizer performs constant folding.

The evaluator walks the resulting AST and produces the final value.

This separation made the implementation easier to reason about and test.

For example:

2 + 3 * 4

initially becomes something conceptually like:


+
├── 2
└── *
    ├── 3
    └── 4

The optimizer can then reduce the constant expression to:

before evaluation.

But "It Compiles" Isn't Proof

This was where the project became much more interesting.

A port can compile.

A port can have unit tests.

A port can produce the right answer for ten examples.

And still be behaviorally different from the original.

So instead of asking:

"Does my Rust implementation work?"

I asked:

"Does my Rust implementation preserve the behavior that matters?"

That changed how I approached testing.

I built a smoke-test suite based on TinyExpr's original test suite and used it to exercise:

arithmetic
operator precedence
associativity
unary operators
variables
mathematical functions
invalid expressions
NaN behavior
infinity behavior
combinatorics
optimization
power associativity
edge cases

The final test run reached:

30 unit tests + 13 smoke tests passing, with 2 intentionally ignored tests for unsupported custom-function/closure functionality.

That distinction matters.

I didn't want to hide unsupported functionality behind a green test report.

Then Things Broke

And this is where the real engineering happened.

One of the smoke tests initially failed because of something that looked almost trivial:


expected 3.14159
got      3.141592653589793

Another failed around:

pi * 2

The Rust implementation was producing the full precision of f64.

The original compatibility tests were using rounded expected values.

So the problem wasn't simply:

"My calculation is wrong."

It was:

"What exactly are we defining as behavioral equivalence?"

That forced me to think carefully about floating-point comparison rather than blindly matching truncated constants.

Eventually, the tests were adjusted to use appropriate numerical tolerance.

That was an important lesson:

Compatibility isn't always byte-for-byte equality. Sometimes it means preserving semantics within the numerical model of the target language.

The Edge Cases Were the Real Challenge

The most interesting differences weren't always obvious.

For example, the Rust lexer doesn't currently support scientific notation in the same way:

1e3

doesn't become:

1000

in this implementation.

Instead, the lexer sees the numeric portion and identifier separately.

So rather than silently pretending the feature existed, the test suite explicitly documents the limitation.

The same philosophy applied to custom functions and closures.

The original TinyExpr supports mechanisms for registering user-defined callbacks.

Our current Rust implementation uses a fixed set of built-in functions.

So those tests remain explicitly ignored rather than being falsely marked as passing.

That's a small testing decision, but I think it represents an important engineering principle:

A trustworthy test suite should tell you what the software can do, what it cannot do, and why.

One of My Biggest Lessons: Ports Are Not Translations

A naive port looks like:

C code
↓
Rust syntax
↓
Done

Our approach was closer to:

Original behavior
↓
Understand semantics
↓
Design Rust architecture
↓
Implement
↓
Compare behavior
↓
Find differences
↓
Investigate
↓
Fix or document
↓
Test again

That distinction is huge.

For example, the original C implementation uses concepts such as:

{% embed 
C   Rust
malloc/free Ownership + Drop
Raw pointers    References / owned values
NULL    Option
Error codes Result
Tagged flags    Enums
Manual cleanup  Automatic memory management
 %}

The result isn't just C code rewritten using Rust syntax.

It's a redesign around Rust's strengths.

Why TinyExpr Matters

At first glance, a mathematical expression parser seems small.

But that's exactly why it was such a good resurrection target.

TinyExpr sits at an interesting boundary:

small enough to understand, but rich enough to expose real language-engineering problems.

Parsing isn't just about recognizing numbers.

It's about answering questions like:

What binds more tightly?
Is exponentiation left- or right-associative?
How does unary minus interact with powers?
What happens when an expression is malformed?
How should variables be resolved?
What should happen with 0 / 0?
How should mathematical domain errors behave?
When is constant folding safe?
What counts as equivalent floating-point output?

Those are real compiler and interpreter problems hiding inside a tiny project.

The Innovation Wasn't "We Rewrote C in Rust"

The innovation, for me, was the methodology.

We treated legacy software as something that could be understood, tested, reconstructed, and modernized rather than simply abandoned.

TinyExpr became a case study in how older software can be brought into a modern ecosystem while preserving the behavior that existing users depend on.

And that idea scales far beyond expression parsing.

Imagine applying the same approach to:

legacy scientific libraries
old developer tools
embedded utilities
abandoned command-line programs
small infrastructure libraries
educational software
older algorithms that are still useful but difficult to maintain

The goal isn't always to replace legacy software.

Sometimes the goal is to give it a safer future.

What I Would Do Differently

If I could restart the project, I would invest more time in defining the compatibility contract before writing the implementation.

Especially around:

floating-point tolerances
unsupported language features
error semantics
exact edge-case behavior
differences between C and Rust numerical behavior

That would have saved debugging time later.

But the debugging itself was valuable.

Because every unexpected failure forced us to understand the original behavior more deeply.

What Code Resurrection Changed for Me

Before this project, I might have described a successful port as:

"The Rust version produces the expected output."

Now I'd describe it differently:

A successful port is one where you understand the original behavior well enough to explain every important difference in the new implementation.

That mindset completely changed how I approached the project.

We didn't just resurrect TinyExpr.

We built tinyexpr-rs as a safer, more maintainable Rust implementation while using tests to challenge our assumptions about compatibility.

And that's what I think makes legacy resurrection exciting.

The code may be old.

The ideas don't have to be.

What's Next?

There are still areas where tinyexpr-rs can evolve:

better parser diagnostics with source spans
more expression simplification
user-defined functions
additional mathematical operators
a REPL
WebAssembly support
broader compatibility testing

But the foundation is there.

A small C expression engine has become a modern Rust project with a clear architecture, automated tests, optimization, benchmarks, and documented compatibility decisions.

Final Thought

The most valuable thing I built during Code Resurrection wasn't just a parser.

It was a way of thinking about legacy software.

Don't ask only, "Can we rewrite it?"

Ask:

"Can we understand it deeply enough to rebuild it, test it, and give it another life?"

That's what Code Resurrection meant to me.

And that's what tinyexpr-rs represents:
old functionality, new foundations, and a future worth maintaining.``