When Software Stops Obeying Time
Software libraries tend to live in a comfortable world of cause and effect. A value is assigned, a function runs, a result comes out, and the future waits politely for its turn.
Today we’re going to look at a handful of libraries and research systems that throw that idea away, and deal instead with a stranger world.
It is a world where the future can leak into the present. Where a variable might not yet know what it is. Where multiple answers can coexist for a while. Where contradictions are not always bugs, but sometimes part of the model.
That sounds like science fiction, but computer science has been circling these ideas for quite a while. The interesting part is that not all of these systems mean the same thing when they let the future affect the past. Some literally rewrite a program’s timeline. Some use probability and inference. Some search for satisfying worlds. Some preserve reversibility. Some treat disagreement as a signal to stop. Others let the disagreement live on.
Once you start looking, you realise there is not one weird corner here. There are several.
The bluntest form of time travel
The most literal version is a language like Mariposa.
Mariposa does not hide what it is doing. It gives you explicit time-travel primitives like now() and at t:. You can capture a moment in execution, jump back to it, and change something that has already happened. It is gloriously direct.
But Mariposa also has a stern sense of discipline. If you create a genuine temporal contradiction, it does not smile and carry on. It throws a paradox error. If control flow has already depended on a value, and you try to go back and mutate that value in a way that would invalidate what happened, the runtime objects. This is time travel with hard rules and no patience for nonsense.
That makes Mariposa fascinating, because it treats the timeline like something editable, but only up to the point where the edit breaks the logic of the universe.
It is the strict physics version of this story.
The elegant functional trick
Then there is Tardis in Haskell, which sounds dramatic, but is really much more restrained.
Tardis lets state flow forwards and backwards through a computation. That makes certain kinds of algorithms surprisingly elegant. You can structure things as if information from later in the computation is already available earlier on.
This looks like time travel, and in a sense it is, but it is not really about paradox. It is about tying the knot neatly. It is a disciplined way of structuring self-referential state, not a system that wants to stare contradictions in the face. If things fail here, they tend to fail in the functional-programming way, through undefinedness or non-termination, not by presenting you with a rich catalogue of competing outcomes.
So Tardis belongs in this strange landscape, but it is a very civilised resident.
The worlds that never had to be singular
From there, the trail leads into probabilistic programming.
Languages and libraries like Church, WebPPL, Anglican, Pyro, and Infer.NET also deal in multiple possible worlds. They are full of uncertainty, branching possibilities, and values that only make sense once more evidence arrives. To a casual observer, they can look as though they are doing the same trick. The future changes the meaning of the past.
But they are really doing something else.
Probabilistic programming systems do not usually ask, “can I rewrite history?” They ask, “given what I know, which histories are plausible?” They describe generative processes, introduce observations, and use inference to weight different worlds. Contradictions do not become interesting runtime artefacts in their own right. They simply collapse under the rules of the model. An impossible world gets probability zero. An unlikely one survives, but barely.
That is a beautiful approach, but it has a different temperament. It treats ambiguity statistically.
The worlds that must satisfy the rules
Another route through the same forest leads to logic and constraints.
miniKanren and its .NET relatives, Microsoft Solver Foundation, truth maintenance systems, assumption-based truth maintenance systems, and propagator models all have a similar effect on the mind. They make software feel less like a sequence of commands and more like a negotiation among requirements.
In a relational or constraint-based system, you do not always compute an answer directly. Sometimes you describe what must be true, and let the machinery search for assignments that satisfy the model. In a truth maintenance system, you track which assumptions support which conclusions. In a propagator system, information seeps through a network of connected cells until nothing more can be refined.
These systems can absolutely feel as if they are working backwards. But again, the key difference is in how they treat disagreement.
A solver tries to find a satisfying assignment.
A logic engine backtracks.
A truth maintenance system isolates incompatible assumptions.
A propagator network keeps pushing information until it reaches a stable state.
In all of them, disagreement is something to resolve, explain, or fence off.
That matters, because eventually we reach a library that answers differently.
The systems that refuse to lose information
Before that, there is one more family worth visiting: reversible computing.
Languages like Janus and Sparcl care deeply about running computation backwards, but not in the same sense as time travel. Their question is not, “can the future alter the past?” It is, “can every step be undone?”
That is a stricter and more formal ambition. Nothing important can be thrown away. History must remain recoverable.
These systems are elegant, and in some contexts very powerful, but they are aiming at invertibility, not temporal ambiguity. They preserve the path. They do not ask what to do when the path forks and refuses to rejoin.
The places where superposition is not a metaphor
Then we step into even stranger territory.
Tower, from the OOPSLA 2022 work on quantum data structures, and Q-Sylvan, a quantum decision diagram simulator, inhabit a world where superposition is not just a literary device. It is the substrate. These systems are concerned with representing and manipulating genuinely superposed states in ways that respect quantum constraints or allow large-scale symbolic simulation.
This is the point where most comparisons to ordinary libraries start to wobble. The mathematics is more demanding, the semantics are stricter, and the goal is different. These tools are not mainly trying to make ordinary developers comfortable with strange values in ordinary code. They are building formalisms for worlds where multiplicity is fundamental.
Which makes them fascinating, but also makes them less immediately relatable.
And that is exactly why the next stop is so interesting.
PositronicVariable, or what happens when software lets disagreement survive
After walking through all these other approaches, PositronicVariable comes into focus properly.
Not as “the one with the weird name”, and not as “yet another library where the future matters”, but as something with a very particular personality.
PositronicVariable takes the idea of future-defined values and brings it back into an imperative developer experience. It does not require you to think primarily in factor graphs, relational queries, reversible semantics, or quantum circuits. It works much closer to the feeling of ordinary programming, except the variables are allowed to participate in iterative causal loops.
And this is the crucial part: when those loops do not settle to a single clean answer, PositronicVariable does not necessarily panic.
It can represent the result as a multi-valued any(...) state.
That is the moment the whole comparison becomes interesting.
Mariposa says contradiction is a paradox, stop the program.
Probabilistic systems say contradiction means impossible, discard that world.
Constraint systems say contradiction means unsatisfiable, search elsewhere.
Truth maintenance systems say contradiction must be tracked and isolated.
Reversible systems avoid the issue by design.
Quantum systems absorb multiplicity into a formal substrate.
PositronicVariable says something stranger.
It says that if repeated execution leaves you with a stable plurality, then perhaps plurality is the result.
That is a genuinely different stance.
It turns disagreement into data.
And that small shift changes the emotional texture of the whole thing. Instead of treating paradox as failure, it treats it as a shape the program can expose. Instead of insisting that every loop collapse neatly, it allows some loops to stabilise as a set of possibilities. The future does not merely patch the past. The future and past keep negotiating until what remains is something the runtime can hold.
There is something unexpectedly human about that idea.
The charm of the oddballs
Along the edges of this landscape are smaller curiosities. A Fantom talk exploring positronic variables. An old Forth-flavoured oddity called Abundance with claims of running backwards in time. Haskell’s procrastinating variables, which are really about delayed availability rather than paradox. Research around prophecy variables in staged systems like BuildIt. Fantom positronic demo, Abundance, PVars, BuildIt
They are all part of the same broad human fascination: what if software did not have to march forwards so obediently?
Most of them answer in partial, cautious, or specialised ways.
PositronicVariable feels unusual because it answers in a way that is both playful and concrete.
Why this matters
It would be easy to dismiss all of this as cleverness for cleverness’s sake. Academic toys. Esoteric abstractions. Programming languages having a late-night conversation with physics.
But there is a reason these ideas keep resurfacing.
Real software is full of circularity. We infer things from outcomes. We revise earlier assumptions in light of later evidence. We let one part of a system act on expectations about another part that has not finished yet. We constantly pretend our programs are simple chains of cause and effect, while quietly building systems full of feedback, revision, and negotiation.
Most libraries deal with that by hiding the mess.
The interesting ones expose it.
And that is what makes this corner of computing so compelling. Not that it breaks time, but that it forces us to admit how often our software was never truly linear to begin with.
If you start from that point, PositronicVariable stops looking like a gimmick and starts looking like one very bold answer to a serious question:
What should a program do when reality refuses to settle on just one past?
Top comments (0)