Research

Where the WHERE goes


f1r3lang is a shipped language with an active research program behind it, published as working notes with runnable code. The program is one idea widened twice: the comprehension has a where clause, and that slot turns out to hold far more than anyone asked of it in 1974. First — where do the pattern and the condition come from? Second — what happens when the condition stops answering yes or no?

Languages all the way down

A condition like Chi(spec) is a claim about structure, so there must be a notion of what structure a specimen has. In SQL that comes from the schema. In f1r3lang it comes from a language definition — and it is a great deal more than a schema.

A Theory declaration has four rungs. The first names the grammar: what terms exist. The second adds equations — the invariants every codebase currently maintains by hand, in comments the type system cannot read: this is a list, but order doesn't matter; compare this string case-insensitively. Pattern matching then happens up to those equations, so nobody ever writes a normalisation function or hits the bug where two spellings of one value meet. The third rung adds rewrites — rules that make the data move on its own. The slogan is: the data can wiggle.

The fourth rung makes a definition a module: a theory takes other theories as parameters, renames what it inherits, and combines with its siblings over a shared ancestor rather than beside one — so parallel composition is "commutative monoid, carrier renamed," and associativity arrives with the parameter instead of being restated. Sharing is a claim the compiler holds you to: two theories that arrived by different routes are two things, and if they share a name, that is a diagnostic rather than a silent override. Definitions live in Module declarations and import by address, not path — a language definition published on chain has an address, and importing it is the same act whether it came from the next directory or another party's node.

From one declaration, the toolchain generates the parser, the printer, substitution, and the rewrite engine. And the connection back to the language is one sentence: a channel's type is a language definition. Sending on a channel means sending a term of that language — two agents can exchange programs in a domain-specific language built for the purpose, and the recipient knows exactly what it received.

Rungs populatedThe familiar name
types + termsalgebraic data types — what a schema can already say
+ equationsthe invariants your type system cannot read, made machine-checkable
+ rewritesdomain-specific languages — data with its own dynamics
+ parametersmodules, in the sense of ML functors — theories built from other theories

The rho‑calculus itself — the theory f1r3lang runs on — is expressible as one such definition among others, in the same block a developer would use for an invoice format. The calculus is not privileged. That is the point.

Widening one

Conditions are generated, not designed


The vocabulary available in a where clause is not a fixed list of built-in predicates. It is constructed from the language definition that types the channel. Change the definition, and the condition language changes with it, automatically. Every other system ships the predicates its designers anticipated, and the escape hatch — a user-defined function — is opaque to everything. Generated conditions have no escape hatch because they have no fixed list to escape from.

Three kinds of sight come out, at three prices. Structural conditions ask what a term looks like — including conditions on namespaces, whole regions of the address space, because names are quoted terms and a condition can descend into them. Behavioural conditions ask about the future: does this specimen, if poked, do a certain thing — one step of this rule is possible here, and afterwards such-and-such holds. And the choice of container for the evidence is a dial: sets give ordinary Boolean logic ("does this hold?"), linear containers give resource logic ("is there exactly one of these, to be consumed once?"), and coalition containers ask about populations ("is there a group of these that, together, can bring something about?") — quorum questions, asked without running a protocol.

Measured on a working example, the cheap rungs of that ladder delivered 92% of the total gain for a third of the total cost — structural sight is the bargain, behavioural sight is the luxury, and the right position on the dial is an economic fact about the deployment environment, not a matter of rigour.

Widening two

When yes or no isn't the answer


A guard returns a truth value, and the communication fires or does not. That is one choice, not the only one. Let the condition return a value — a probability, a rate, a cost — and read it as how much this candidate happens rather than whether.

The reassurance first: when the values are plain Booleans, nothing changes. No existing program acquires a new meaning. A developer who never grades a condition never encounters any of this.

A developer who does gets the same program text as three artefacts. Over Booleans it is what it always was: code committing transactions. Over rates it becomes a stochastic simulation of a population of itself — running it many times gives the distribution of outcomes, which is how you ask "if this contract is deployed a thousand times against that environment, what happens?" in the language the system is written in, with no separate model to drift. And in the measured example — a forager with a finite budget, deciding whether to open specimens — the graded clause is the learning rule: the belief update turns out to be a correctly conditioned, unconditionally stable gradient step. Machine learning fell out; none was imported.

The graded readings run in a separate simulator, off the consensus path, by design. And one honest fence: a restricted fragment admits a complex-valued, quantum-style reading — a real construction for circuit-shaped programs, not a claim that f1r3lang is a quantum language.

Values in the clauseRunning the program means
Booleansexecuting, exactly as today
non-negative realsa stochastic simulation of a population
graded beliefs (PLN)probabilistic inference driving execution
best-explanation (Viterbi)finding the most likely path
costs (tropical)finding the cheapest path
complex amplitudesa quantum-style simulation, on a fenced fragment

Honesty about status

What actually runs


Nothing here silently pretends that a plan is a product. Three words a reader has every right to keep apart: specified means the surface is frozen and written down; implemented means there is code a reader can run; planned means neither yet.

CapabilityStatus
Theory declarations: types, terms, equations, rewrites; generated toolchainImplemented — in the reference elaborator and the language-definition toolchain, with definitions shipped for the lambda calculus, the rho‑calculus, and others.
The fourth rung: parameters, exports, replacements, the algebra of theoriesImplemented as a dependency-free reference elaborator on a branch of the Rust node, with the universal-algebra tower and the rho‑calculus as its worked corpus — plus a corpus of negative cases for the diagnostics.
The same surface in the live parserNot yet — the grammar delta sits beside the elaborator as a patch, and the elaborator is not on the node's workspace build. The honest boundary of this section.
Module, and imports by addressSpecified and implemented in the elaborator; resolution is a compile-time step in the client toolchain, so a node never fetches anything.
where guards + cost accountingImplemented on a branch of the Rust node, with a transpiler, runnable examples, and compile tests — including a worked supply-chain demonstration with conserved money and inventory.
Conditions from the generated logicPlanned. The guard slot exists and is evaluated before commit, but a condition today is an ordinary boolean expression; connecting an elaborated theory to the guard is what would close the gap.
Graded conditions & simulationImplemented as a separate simulator crate — stochastic and quantum readings built and tested — deliberately not part of the node's execution path.

Go deeper

The working notes


The research is published as a series of working notes by L.G. Meredith. The developer-facing entrance is f1r3lang for the Working Software Developer — readable right here; the theory-first entrance is Graph-Structured Lambda Theories. Neither is a prerequisite for the other. Several earlier notes predate the name and speak of internal code names or "rholang 1.4" — they are the same language.

Start at the shallow end