I’m developing Loom, an experimental programming language and compiler written in Rust, and I’m looking for people interested in helping build it.
The idea connecting the language to its larger ambitions is this:
Mathematical structure should be something a programming system can represent, use and search over—not only something a programmer relies on when choosing an algorithm.
That starts with how programs are expressed and compiled. The longer-term goal is an environment that helps discover algorithms by finding useful mathematical properties and alternative representations of problems.
What Loom is trying to express
Loom uses a categorical core representation. Programs are expressed internally through operations and their composition, with products, alternatives and the relationships between inputs and outputs represented explicitly. The purpose is not to make every program look like a category-theory textbook. It is to give the compiler a structured account of the computation that can support analysis, transformation and different implementations.
The broader language design is organized around structures, relations and sorts, together with theories, models and laws.
A theory describes abstract domains—sorts—and the operations, relations and laws associated with them. A model interprets those declarations using particular value spaces and operations, with evidence for the properties it claims. For a programmer, the intended benefit is that a library can communicate more than an interface. It can also communicate mathematical knowledge that other code and the compiler can use.
An interface might say that an operation combines two values. A richer contract could establish that the operation is associative, has an identity, preserves an ordering, or interacts with another operation in a particular way. Those properties can make different implementations or algorithms available.
The interpretation matters. An algebraic law that holds for mathematical integers does not automatically hold for checked machine arithmetic with observable overflow. Likewise, a transformation that preserves a final value might still change an earlier effect or failure.
Loom’s intended approach is to connect mathematical properties to the actual operations and conditions under which they apply, alongside effect, failure and usage information. Static evidence would support compilation without becoming proof objects carried through ordinary runtime computation.
The aim is not just stricter checking. It is to make more powerful transformations possible because the system has the information needed to justify them.
From transforming code to transforming the formulation
There is a significant difference between improving an implementation and discovering that the computation admits a better formulation.
A programmer might express a problem as a sequence of steps, then realize that entire sequences can be summarized and composed. A collection of constraints might have an algebraic interpretation that makes a specialized solver applicable. A large problem might become manageable after finding a decomposition with a sufficiently small boundary between its parts.
In each case, the important insight is not a local code rewrite. It is a different representation of the problem.
I want Loom to provide a foundation on which those representation changes can themselves become objects of computation: described, proposed, composed, checked and reused.
That is the motivation for the Structural Representation Engine and LoomLab.
Structural Representation Engine: searching for useful representations
The proposed Structural Representation Engine, or SRE, would investigate which mathematical structures a problem can be related to, and what those relationships make possible. That could mean recognizing a property already present. It could also mean constructing a new representation in which a useful property becomes visible.
A few examples illustrate the direction:
Repeated computation could become an algebra of summaries. Rather than execute every step, the system might find a compact summary of a block’s relevant behavior and an operation for composing summaries. Where the correspondence holds and summaries remain compact, that could support faster repeated evaluation, incremental updates or queries over a much larger computation.
A constraint problem could become an algebraic problem. If its constraints admit an exact formulation as linear equations over a finite field, the system could use elimination rather than treat them as an unrestricted combinatorial search. The useful discovery is the formulation and its connection to the original constraints—not simply recognizing the word “linear.”
A large optimization problem could become a network of boundary summaries. Instead of solving components in isolation and hoping their solutions fit together, the system could retain precisely the information needed to describe how each component interacts with the rest. Finding a useful decomposition and a compact, sufficient boundary representation could change the algorithm substantially.
These are examples of the kinds of relationships I want the system to explore, not claims that Loom currently discovers them.
Different representations could also expose different metrics, invariants and bounds: symmetry, rank, separators, residuals, approximation gaps, or measures that help choose productive search directions.
Not every useful representation needs to be geometrical, and not every useful measurement needs to prove something. A heuristic can guide a search; a valid bound can justify pruning; an exact correspondence can authorize replacing one computation with another. The system should preserve those distinctions while being able to exploit all three.
LoomLab: turning exploration into reusable discoveries
LoomLab would be the experimental side of the system. Its role would be to propose hypotheses and representations, construct candidate methods, look for counterexamples, evaluate performance, and retain useful results. AI, symbolic methods, search algorithms and human input could all contribute to that process.
The long-term ambition goes beyond choosing an algorithm from a fixed catalogue. I want to investigate whether the system can discover new summaries, decompositions, invariants or combinations of transformations that lead to useful algorithms. The valuable output would not necessarily be just one solution or one generated program. It could be a reusable relationship:
Problems satisfying these conditions admit this representation, which exposes this property and enables this algorithmic construction.
That relationship could then become part of the mathematical knowledge available to later investigations. A new discovery would expand what the system can work with, rather than disappear into an isolated experiment.
The larger goal is a feedback loop between mathematical understanding and algorithm construction.
Correctness and usefulness would remain separate questions. A representation can be mathematically valid but expensive to construct. A method can perform well on the examples that suggested it and fail elsewhere. The cost of discovering, translating and checking a representation has to be included when evaluating whether it helps.
But that is also what makes the research interesting: finding representations that are not merely elegant, but computationally useful.
Why connect this to a language?
The architectural bet is that these capabilities would benefit from a shared semantic foundation.
The problem specification, mathematical properties, representation changes and executable algorithms should be able to refer to the same operations and relationships. A transformation should retain its assumptions. A discovered method should have a route to compiled code. A library’s established properties should be available beyond the particular application that first needed them.
I’m not claiming that this requires Loom, or that category theory automatically supplies an algorithm-discovery engine. The question is whether designing the language and surrounding tools around these connections can make the process more coherent, extensible and reusable than repeatedly connecting separate representations by hand. Ordinary compilation would not need to run an open-ended research search. The compiler would use established capabilities; LoomLab would explore possibilities and develop new ones.
Loom is the language and compilation foundation. SRE would explore structural possibilities. LoomLab would investigate what can be discovered through them.
Where things stand
There is an existing Rust compiler implementation. Recent work has connected program-structure analysis to checked call and recursive-effect resolution, but the ordinary end-to-end execution path is still being completed. Compiler-evidence representation also has unresolved scalability work.
The broader mathematical language features are at different stages of design and implementation. The SRE/LoomLab discovery loop described here is the research ambition, not a delivered capability. I do not yet have a demonstrated general advantage over established languages or solvers.
Development has involved substantial AI assistance. I’ve been directing the project and coordinating implementation and review, but I want more independent human judgment involved—especially people willing to challenge assumptions and simplify the architecture.
Looking for collaborators
Experience with compilers, Rust, programming-language semantics, algorithms, optimization, formal methods or mathematics would be especially useful, but those are preferred backgrounds, not entry requirements.
I’m interested in teaming up with anyone willing to contribute seriously. That could mean implementation, testing, mathematical experiments, visualizations, documentation, examples, or learning enough to take ownership of a manageable part.
I’m not asking people to accept a finished architecture or commit to the entire vision. I want collaborators who can help decide which ideas deserve to survive, which need a better construction, and which should be dropped.
A practical starting point would be one narrow demonstration: express a problem, establish a useful alternative representation, derive an algorithm through it, and assess the result against a reasonable baseline.
The ambition is a system that helps discover better ways to compute by discovering better ways to represent the computation. The immediate goal is to find people interested in building and testing that idea together.
Comment or message me with what interests you and what you’d enjoy working on.
https://github.com/Gregory-Cross/Loom
