Perpetua

On the Design, Semantics, and Cultural Reception of the First Non-Halting Programming Language

1. Background

Every programming language in widespread use is founded on the same structural metaphor: the tree. Source code is parsed into an abstract syntax tree, a hierarchical structure with a root node at the top and leaf nodes at the bottom, and execution proceeds by traversal from root to leaves, with the expectation — sometimes enforced, sometimes hoped for — that the traversal will eventually terminate. The program starts. The program does something. The program stops. This is considered desirable.

Perpetua does not have a tree. Perpetua has a ring.

The abstract syntax ring, or ASR, is a directed cyclic graph in which every node has exactly one successor and exactly one predecessor, and the last node’s successor is the first. There is no root, because a ring has no top. There are no leaves, because a ring has no bottom. There is no entry point and no exit point, because a ring has no beginning and no end. Execution proceeds around the ring, and when it reaches the node it started from, it continues, because there is nothing in the structure to indicate that arrival is different from departure. A valid Perpetua program will provably never halt. This is not a limitation of the language. It is the language’s central guarantee.

The halting problem — Turing’s 1936 proof that no general algorithm can determine whether an arbitrary program will terminate — has preoccupied computer science for nearly a century. Perpetua resolves it. Not by solving it, which is impossible, but by eliminating the condition under which it arises. The halting problem asks: will this program stop? Perpetua answers: no. The question is decidable in every case because the answer is the same in every case. The proof is trivial and fits on an index card, which its designer, Prof. Håkan Lindqvist of Uppsala, reportedly mailed to several Turing Award recipients in 2021 without explanatory context. Two replied.

2. Language Design

Perpetua’s syntax is minimal by necessity. A language whose programs never halt cannot afford verbosity, since every token will be executed infinitely often and the cumulative aesthetic cost of an ugly expression is, over infinite iterations, unbounded. Lindqvist described this principle in his original technical report as “the moral argument for concision,” and it is the closest the language specification comes to a statement of values.

A Perpetua program is a sequence of expressions arranged in a ring. The compiler verifies that the ring is well-formed — that every node has exactly one successor, that the graph is connected, that there are no termination points — and rejects any program containing a construct that could cause execution to stop. The return keyword does not exist. The exit function does not exist. Exceptions, if raised, propagate around the ring until they arrive back at the point of origin, where they are raised again. An uncaught exception in Perpetua is not a crash. It is a mood.

Variables in Perpetua are mutable by default, because immutability implies a value that has been computed once and for all, and the language’s semantics do not admit the concept of “once and for all.” A value that does not change over infinite iterations is not immutable — it is dead, and Perpetua’s liveness checker will reject it. Every binding must be modified at least once per cycle, a constraint the language specification calls the vitality requirement. A program in which a variable is assigned and never reassigned is not merely wasteful. It is, in the language’s type system, ill-formed. The compiler error reads: vitality violation: binding 'x' exhibits no change across one full cycle. A living program does not hold still.

Control flow is, necessarily, unconventional. Perpetua has no if-then-else, because a conditional branch implies the possibility that one path is not taken, and a path not taken is a path that terminates. Instead, Perpetua offers when-also, in which both branches execute on every cycle, weighted by a confidence value between 0 and 1 that determines how much of each branch’s effect is applied. A when-also with confidence 0.9 for the first branch and 0.1 for the second does not choose — it blends. The result is that a Perpetua program in its steady state does not compute a single value but a weighted superposition of all values it could have computed, which Lindqvist calls the “semantic haze” and which the documentation, in a rare moment of editorialising, describes as “the program’s opinion of itself, revised continuously.”

Loops do not exist as a syntactic construct, for the obvious reason that the entire program is a loop and additional loops would be, as Lindqvist noted, “a ring within a ring, which is a torus, and we are not yet ready for toroidal computation.” This statement appears in a footnote to the language specification and has generated a small but committed community of researchers who believe it constitutes a promise. Lindqvist has not commented.

3. Type System

Perpetua’s type system is organised not around safety, which concerns itself with preventing bad things from happening, but around liveness, which concerns itself with ensuring that things continue to happen. The distinction is foundational. A safe program is one that does not crash. A live program is one that does not stop. These are not the same property, and optimising for one does not optimise for the other, a fact that Perpetua’s type system embodies with some rigour.

The base types are Flux, Drift, and Pulse. A Flux is a value that changes continuously — the language’s equivalent of a number, though calling it a number would imply that it might at some point hold still. A Drift is a value that changes slowly, used for configuration and environmental state that evolves over cycles but is not expected to change on every iteration. A Pulse is a boolean that alternates between true and false on every cycle, which is the only form of boolean the language permits, since a boolean that remained permanently true or permanently false would violate the vitality requirement.

There is no Void type. Void implies nothingness, and nothingness implies termination. There is instead Residue, which is the type of a computation that produces nothing useful but continues to execute. Most Perpetua programs, in the author’s experience, produce a great deal of Residue.

The type checker enforces what the specification calls the perpetuity constraint: every well-typed program must be provably non-terminating. This is verified by a static analysis pass that confirms the ring structure is complete, that no branch can reduce the program to a fixed point, and that the vitality requirement is satisfied for all bindings. Programs that might halt are rejected. Programs that will definitely not halt are accepted. Programs whose halting status is undecidable are rejected, on the grounds that they might halt, and the language does not tolerate ambiguity on this point.

4. Standard Library

The standard library is small, as the design space for functions that never return is narrower than one might assume and wider than one might hope.

The I/O module provides emit, which sends a value to an output stream on every cycle, and absorb, which reads from an input stream on every cycle. There is no print, because printing implies a completed statement, and there is no read, because reading implies waiting, and a program that waits has, for the duration of the wait, stopped. absorb does not wait. If no input is available, it returns the previous input, on the theory that the most recent observation of the external world is a reasonable substitute for a current one, a design decision that the documentation attributes to “realism about the availability of external reality.”

The collections module provides Ring, which is the only data structure. It is an ordered collection with no first or last element, iterated by rotation. Indexing into a Ring is modular: index 0 and index n (where n is the length) refer to the same element, and negative indices rotate in the opposite direction. There are no arrays, because an array has a beginning and an end. There are no stacks, because a stack implies that something might eventually be empty. There are no queues, because a queue implies that items arrive and depart, and departure is, in the language’s ontology, a kind of death.

The concurrency module provides entangle, which links two rings such that they rotate in synchrony, and drift-apart, which allows them to desynchronise gradually over time. There are no locks, because a lock implies that a thread of execution might stop and wait, and waiting is not permitted. Concurrent Perpetua programs do not synchronise. They coexist, occasionally influencing each other through shared Drift values, like planets in adjacent orbits whose gravitational effects are felt but whose coordination is no one’s responsibility.

5. Cultural Reception

Perpetua has been adopted in production by no major company, used in teaching by no accredited university, and recommended by no industry analyst. It has, however, attracted a community of approximately four thousand developers who maintain an active forum, an annual conference (PerpetuaCon, held in Uppsala, which has never concluded — the first conference began in 2023 and is technically still in session, with attendees rotating in and out on a schedule maintained by a Perpetua program), and a package registry containing 347 libraries, all of which are running.

The community’s relationship to mainstream software engineering is one of polite mutual incomprehension. The question most frequently asked by outsiders — “What is Perpetua for?” — is considered by the community to be malformed. A language whose programs never halt is not for anything in the sense that a hammer is for nails. It is against something: against the assumption, embedded so deeply in computational culture as to be invisible, that the purpose of a program is to produce a result and then stop. “You do not ask what a river is for,” Lindqvist said in a 2024 interview, and then declined to elaborate, which is characteristic.

The community has produced one artifact of note beyond the language itself: a twelve-page document titled The Perpetua Manifesto, which argues that the assumption of termination is the foundational error of Western computing, that Turing’s formalisation of the halting problem was not a discovery but a symptom of a culture that cannot conceive of value in continuation, and that the true purpose of computation is not to arrive at answers but to sustain processes. The manifesto has been cited in three doctoral theses, all of them in philosophy departments, and none of them with Lindqvist’s approval.

Lindqvist himself maintains that Perpetua is a programming language, not a philosophy, and that the community’s tendency toward metaphysical extrapolation, while understandable, is a category error. He has said this at three consecutive PerpetuaCons. The community has listened respectfully each time and continued extrapolating.

6. The Termination Incident

In September 2024, a Perpetua program halted.

The program — a monitoring daemon written by a contributor in São Paulo — had been running continuously for eleven months when it produced a final output, closed its file handles, and stopped. The event was detected by the community’s liveness dashboard (itself a Perpetua program) and produced immediate alarm. An emergency session of PerpetuaCon was convened. Lindqvist was contacted. The program’s source code was examined by fourteen reviewers over three days.

The cause was eventually identified. The program contained a dependency on a C library, invoked through Perpetua’s foreign function interface, that performed a malloc on every cycle. After eleven months of continuous execution, the host machine’s memory was exhausted, and the operating system killed the process. The program had not halted. It had been halted — from the outside, by a system that did not share its values.

The community’s response was vigorous. A proposal was submitted to the language specification requiring that all Perpetua programs be executed on machines with infinite memory, a requirement the specification committee acknowledged was “aspirational.” A more practical proposal suggested that the FFI be removed entirely, severing Perpetua’s connection to the world of terminating languages. This proposal was debated for six weeks and remains under discussion.

Lindqvist’s own response was brief. He noted that the program had not violated the language’s guarantees — it had been provably non-halting within its own semantics, and had only stopped because the substrate on which it ran was finite. “Perpetua programs do not halt,” he wrote in a post to the community forum. “The universe halts them. This is not the same thing, and the distinction matters, though I grant that from the program’s perspective it is academic.”

The post received 1,247 upvotes. No one replied. There was nothing to add, and the forum, unlike a Perpetua program, permits silence.

7. Conclusion

The author does not use Perpetua. The author does not know anyone who uses Perpetua for work that could be described, under any reasonable definition, as productive. The language is impractical by design, limited by conviction, and non-terminating by construction. It produces no outputs that could not be produced more efficiently by any conventional language, and it produces them forever, which is longer than most stakeholders are prepared to wait.

And yet the language persists — which is, given its semantics, the minimum one would expect, but which is also, the author suspects, the point. Every other language promises to finish. Every other language is organised around the assumption that computation is a means to an end, that the program is a servant dispatched on an errand, and that the servant will eventually return with the answer and then stand quietly in the corner until needed again. Perpetua refuses this. It insists that the computation is not an errand but a condition — that the running of the program is not a phase to be completed but a state to be inhabited.

Whether this constitutes a contribution to computer science or to something else is a question the author leaves to the reader, while noting that the question itself has no termination condition and may therefore be, in the strictest sense, a Perpetua program.

The author thanks Prof. Lindqvist for his cooperation, which took the form of a single email reading “I have answered your questions in the order received. The answers are: no, yes, I don’t know, and that is not what I said.” The author found this sufficient.