Semantics of semantics in Python with tracing code
Writing software that actually behaves like pure math is harder than it looks. Usually, state changes, loops, and memory quirks get in the way, turning elegant logic into a tangled mess of side effects. A modern tracing library fixes this by acting as a silent observer. It watches your program execute, sweeps away all the temporary memory junk the computer needed to do the work, and leaves behind a perfect, permanent map of how your data actually flows. By completely separating how the code runs from what the math is, you get a flawless, auditable blueprint of your system. It gives you the exact precision needed to stop fighting your language's quirks and start engineering truly smooth, reliable software.
And so last year I wrote a first draft of a Python tracing library (see original https://github.com/equational/hltpy ). This code works, but fails to be elegantly re-entrent: it is tricky to trace interpretations of traces. So today, pressured by a needy use case, I am rewriting this library.
How to pick up code you wrote almost a year ago
A first issue, is that this code is incredible detailed. It needs to understand as much Python semantics as possible, it contains tons and tons of small decently complex code. I know I do not remember everything, so how best to "relearn" and "refresh" memories built a year or more ago?
This is how I typically relearn code:
- I get a code diff of the last big change I did, or was doing (if incomplete), and I read through the diff.
- We are finding our previous "state of mindful flow", and that will bring back the memories from that moment.
- I rewrite that diff, or I rewrite a bigger portion of the code. The idea is that there will always be need of code clean-up, very few codes are perfect.
- The flow is an active flow, I need to place myself in the same active mental space to truly bring back my memories. I use the opportunities to make myself happy by making my code better. Or when possible, I directly start on delivering the changes that are the reason why I am revisiting the code. In this case, I need better capabilities of trace reinterpretation.
The economics of semantics of semantics
Building rockets by trial and error is a fast track to bankruptcy. The defining characteristic of rocket science is that abstract mathematics—not guesswork—drives the engineering. The systems are so highly complex that without a rigorous scientific foundation, achieving profitability or even basic success is impossible.
Embedding pure mathematics into software carries the exact same economic constraints. When you are building math with code, you cannot rely on standard iterative debugging; you must adopt a strict rocket science discipline. This requires a level of precision that fundamentally changes how you interact with the language itself.
To write code with guaranteed, mathematical correctness, standard execution tracking is not enough. You must operate on two distinct levels:
- Intercepting Semantics: Capturing the base computational behavior of Python.
- Intercepting Meta-Semantics: Capturing the semantics of the semantics—tracing the tracing logic itself.
The economics of building big software
Does a massive software system inherently hold millions of dollars in value just because it cost millions to develop? Increasingly, the answer is no.
Large Language Models are challenging the entire foundation of our existing software base by forcing us into a severe software economics squeeze. This nasty reality is defined by two colliding issues:
- Creation is cheaper: The cost of code development has dropped by more than a factor of ten.
- Trust is expensive: The cost of ensuring secure, verifiable software has risen by significantly more.
Because of this squeeze, our old approaches to software development are no longer viable. The new era requires a different architecture—one that solves for trustworthy execution semantics first, rather than trying to force-fit LLMs into outdated development cycles.