I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nHere is the whole thing. Seventy lines, one module and its manifest, compiled on the current toolchain. Walk it top to bottom and every construct the series introduced that the compiler has today appears once.
\nmodule RateLimiter implements GenReactor(Event = Allowed | Denied)\n\n@moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\"\n\nimport GenReactor.{type Reply, NoReply}\n\n%% Constants, evaluated at compile time. A public one is exported.\npublic const default_plan = \"free\"\nconst key_pattern = \"^[A-Za-z0-9_-]{1,64}$\"\n\n%% A structural type whose field carries a refinement.\ntype Config = {max_tokens: Int & > 0 & =< 10000}\n\n%% Relation role: facts you look up.\nrelation Plan = {name: String, max_tokens: Int}\nfact Plan(name: \"free\", max_tokens: 10)\nfact Plan(name: \"pro\", max_tokens: 1000)\n\n%% Constraint role: facts you impose on the store.\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\n\n%% Event role: what the store tells the world.\nevent Allowed = {id: String, remaining: Int}\nevent Denied = {id: String}\n\n%% Rewrite rules over the store.\nrule consume_token =\n on Request(id: rid) as req, Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove req, bucket\n when t > 0\n tell Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n end\n\nrule deny_when_empty =\n on Bucket(id: rid, tokens: 0), Request(id: rid) as req\n remove req\n tell Denied(id: rid)\n end\n\n%% The process that owns the store.\npublic function init(_args) ->\n Ok([])\n\npublic function handle_event(Allowed() as v, _ctx) -> Reply(value: v)\npublic function handle_event(Denied() as v, _ctx) -> Reply(value: v)\npublic function handle_event(_, _) -> NoReply()\n\npublic function start_link() ->\n GenReactor.start_link(__MODULE__, [], [])\n\n%% Functions.\npublic function plan_limit(name: String) ->\n query Plan(name: name, max_tokens: m) end\n\npublic function create_bucket(server, id, cfg: Config) ->\n GenReactor.tell(\n server,\n Bucket(id: id, tokens: cfg.max_tokens, max_tokens: cfg.max_tokens)\n )\n\npublic function request(server, id: String) ->\n case Re.matches(id, key_pattern) of\n true -> GenReactor.tell(server, Request(id: id))\n false -> Error(:invalid_key)\n endThe project describes itself in manifest.bcl:
import Library\n\nmanifest: Library.Manifest & {\n project: {\n name: :limiter,\n version: \"0.1.0\",\n description: \"A token bucket rate limiter\"\n }\n}Constants. default_plan and key_pattern are evaluated when the module compiles, not when it runs. default_plan is public, so another module reads it as RateLimiter.default_plan. key_pattern is private. request checks an id against it with Re.matches before it tells the store, and a malformed id gets Error(:invalid_key). A constant must be an expression the compiler can evaluate, so the pattern is kept as a string and compiled when it is used.
Functions. plan_limit, create_bucket, request. Functions over immutable values, pattern matching in the heads, let bindings that shadow rather than mutate: the functional core you already have on the BEAM, spelled differently. The compiler also knows what each of them may do, which is why t > 0 and any function you call from a guard are checked. The seventh post explains how.
Shapes. Config is a structural type from the third post: a named shape whose field carries its own refinement. Write Config(max_tokens: -3) and the compiler rejects it. Build one from a runtime value and the constructor checks the same rule. Bucket, Request, Allowed and Plan are structural types too, each declared directly in the role it plays.
Relations. Plan is held as facts, and plan_limit asks it a question with query. The sixth post is about this role and the derivation rules that run over it. The limiter only needs the facts, so there is no :- here. To run plan_limit, Plan also needs a relation store, which that post shows. The module leaves it out to stay short. Add relation Includes(plan: String, feature: String) and a recursive rule and you have the transitive queries that post replaces.
Constraints. Bucket and Request are facts in the store that the rules act on. What a bucket is, and what happens to it, are declared next to the type, not spread across a handle_call.
Events. Allowed and Denied are values that leave. They exist for one round of the rules, are seen by handle_event, and are swept away. The fifth post explains the sweep, and why it separates the rule that emits from the process that decides who hears.
Rules. consume_token and deny_when_empty are from the fourth post: they match several facts at once, have guards, and are fired by the store rather than called by you. rid in both patterns is the join.
Processes. implements GenReactor(...), init, handle_event, start_link. A supervised OTP process whose state is the store and whose logic is the rules. The fifth post is about this noun, and how it compares with the gen_statem you would otherwise write.
The manifest. limiter is a library: RateLimiter runs under the supervisor of whichever application starts it, so the manifest names no start_module. The toolchain generates the .app.src from it. The ninth post shows what an application manifest adds, and how a manifest's types reach the code and the releases.
Fluents and signals. Not in this module, because they are not in the compiler yet. The eighth post is the design. When they land, the limiter grows a signal load := ... for how full each bucket is and a fluent for "bucket exhausted since t", and it stays one module.
From Erlang, because that is where most readers will call it from first:
\n{ok, Pid} = 'Bondy.RateLimiter':start_link(),\nCfg = {'Bondy.RateLimiter.Config', 3},\n'Bondy.RateLimiter':create_bucket(Pid, <<\"key\">>, Cfg),\n'Bondy.RateLimiter':request(Pid, <<\"key\">>).\n%% => {ok, {'Bondy.RateLimiter.Allowed', <<\"key\">>, 2}}Compiled modules are named Bondy.<Module>. A value of a structural type is a tagged tuple at runtime, with one element per field in declaration order. So Cfg and the reply read the way they do, and you can pattern match on them from Erlang without a header file. Building the Config on the Erlang side skips its refinement check, so build it in Bondy when the value is untrusted.
The toolchain is a compiler, a REPL and a project scaffold, with rebar3 and Mix integration, on Erlang/OTP 29 or newer. It opens on 21 October, when I show Bondy at Code BEAM Europe. Until then, join us on Zulip: #announcements is where it lands first, and the design discussion is already there.
\nTen posts. The claim was that a mainstream language gives a value one role and makes you tangle every other role into your code by hand. The fix it proposed was to let one kind of value play several roles, each with its own verbs, under one type system. The program above is the claim with a compiler behind it: shapes describe the values, and each role takes one line to declare. Rules and processes sit beside the functions, and the compiler knows what every function may do.
\nOne role and one noun are still design: fluents and signals. The distribution story is OTP's, with Partisan next. The compiler checks that rule guards cannot flip from true to false, but not yet that a rule set terminates. I have tried to say each of those where it applied rather than once at the end. That was deliberate: a language that promises more than it compiles is the thing I wrote this series against.
\nCode BEAM is in a few days. Come and see it run.
\n", "url": "https://bondy.io/posts/2026-10-12-one-module-five-nouns", "title": "One module, five nouns", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language" ] }, { "id": "https://bondy.io/posts/2026-10-12-the-manifest-is-a-module", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nAn Erlang application describes itself in several files. The .app.src says what the application is. rebar.config says what it depends on. sys.config and vm.args say how a release runs it. Nothing checks that the values in sys.config are the ones the application expects. The only description of the configuration an application accepts is the code that reads it.
Bondy puts all of this in one language, the Bondy Config Language (BCL). Apart from its imports, a BCL document holds three things: type definitions, let bindings for reuse, and top-level bindings, which are the document's output. The types are Bondy shapes, and & is the same unification that validates data in Bondy code.[1] So a configuration file has a type, and the compiler checks the file against it.
Each tier has a type in the standard library. Library.Manifest describes a library: an OTP application with modules and no supervision tree. Application.Manifest adds the entry point of the supervision tree and the application environment. Release puts applications together with flags for the virtual machine and a system configuration.
A project has a manifest.bcl at its root, and its manifest binding unifies with one of the two manifest types. Here is the manifest of shop:
%% manifest.bcl\nimport Application\n\npublic type Config = {\n port?: Int & > 0 & < 65536 = 8080,\n pool_size?: Int & > 0 = 10,\n timeout_ms?: Int = .pool_size * 1000\n}\n\nmanifest: Application.Manifest & {\n project: {\n name: :shop,\n version: \"0.1.0\",\n description: \"An online shop\"\n },\n start_module: Shop.App.__MODULE__,\n dependencies: {\n cowboy: { version: \"~> 2.20\" }\n },\n extra_applications: [:crypto],\n env: Config\n}Config is the application environment: every field shop reads, with its type and its default. The ? marks a field as optional, and = 8080 is its default. A default can read another field of the same shape as .field, so timeout_ms follows pool_size.
The toolchain generates the .app.src from this document:
{application,shop, [\n {description,\"An online shop\"},\n {vsn,\"0.1.0\"},\n {registered,[]},\n {mod,{'Bondy.Shop.App',[]}},\n {applications,[bondy,cowboy,crypto,kernel,stdlib]},\n {env,[{port,8080},{timeout_ms,10000},{pool_size,10}]},\n {modules,[]},\n {licenses,[]}\n]}.You don't write the applications list. The toolchain derives it from kernel, stdlib and bondy, the extra_applications, and the name of each dependency. The env list holds the defaults of Config.
The types in the standard library say what a manifest must hold. In Library.Project, name and version are required, and version must match a semantic version pattern. Application.Manifest requires start_module. Leave it out, and the manifest does not finalize:
Cannot build a complete Application.Manifest: field `start_module` is required and was not givenWrite version: "one", and the error names the pattern and the path to the field:
Value \"one\" does not match pattern \"^[0-9]+\\.[0-9]+\\.[0-9]+\"Library.Manifest is the same type without start_module, env and start_phases. A library has no supervision tree, so its .app.src has no mod entry. It can still declare a Config type for the applications that use it.
The toolchain compiles each manifest.bcl into a Bondy module. Its name comes from the application name, one segment for each part between underscores: :shop gives Shop.Manifest, and :acme_pricing gives Acme.Pricing.Manifest. The build compiles this module first, into the application's own ebin. Then it compiles the application's code, which can import the types of its manifest:
module Shop.Settings\n\nimport Shop.Manifest.{type Config}\n\npublic function defaults() :: Config -> \n Config()\n\npublic function tuned() :: Config -> \n Config(pool_size: 20)Config() constructs the value with every default: port 8080, a pool of 10 and a timeout of 10000. Config(pool_size: 20) gives a timeout of 20000, because the default of timeout_ms reads pool_size. The type in the manifest is the type in the code. There is no second definition to keep in step with the first.
The order of the build sets one rule. The manifest compiles before the rest of its application, so it must not name a module of that application. The build refuses such a reference by name:
\nmanifest.bcl names Shop.Settings, a module of its own application; a manifest is compiled before its application, so declare the type in the manifestWithout the rule, an incremental build would find the module from the last build, and a clean build would fail. With it, an incremental build fails too, so the result does not depend on what is left in _build. On a clean build, the reference fails as an unknown module.
A BCL document can call functions of the Bondy standard library, so it can compute a value. The compiler checks the document as one unit, with one allowance: reading environment variables.[2] The compiler refuses a call that needs any other capability. This document builds:
\ncfg: {\n host: System.get_env(\"SHOP_DB_HOST\", \"localhost\"),\n name: String.uppercase(\"shop\")\n}With SHOP_DB_HOST unset, host is "localhost". With SHOP_DB_HOST=db1.internal, it is "db1.internal". The compiler refuses a field that calls File.read/1, and the call never runs:
Function cfg/0 requires capabilities not permitted in a safe-mode unit. Its capability set must be within the unit's allowance (the capabilities the host granted this unit). Route effectful work through a granted capability.So a dependency's manifest, which your build loads, can't read your files, write to a table or create atoms.
\nA release lives in releases/<name>.bcl. It names the applications to include, the flags for the virtual machine and the system configuration. The section for each application can use that application's Config, because the release imports the manifest module like any other module:
%% releases/shop.bcl\nimport Release\nimport Shop.Manifest\n\nrelease: Release & {\n applications: [:shop],\n vm: VM & {\n name: System.get_env(\"NODE_NAME\", \"shop@127.0.0.1\"),\n async_threads: 64\n },\n sys_config: {\n kernel: { logger_level: :warning },\n shop: Shop.Manifest.Config & { port: 80 }\n }\n}The release sets only the port. Unification with Config supplies the other fields from their defaults, and the toolchain writes the result as sys.config:
[\n {kernel, [\n {logger_level, warning}\n ]},\n {shop, [\n {port, 80},\n {timeout_ms, 10000},\n {pool_size, 10}\n ]}\n].It writes the vm section as vm.args:
-name shop@127.0.0.1\n+A 64Give the port as 70000, and the release does not compile. The compiler sees that no value satisfies both the release and the type:
this intersection: `Config & {port: 70000, ...Any}` denotes no value: no value is a member of every conjunctThe team that writes the release and the team that writes shop can be different. The type is the contract between them, and the compiler checks it.
Values that change between environments live in config/. config/base.bcl patches every environment, and config/<env>.bcl patches one:
%% config/prod.bcl\nrelease: {\n vm: {\n name: System.get_env(\"NODE_NAME\", \"shop@10.0.0.5\")\n },\n sys_config: {\n kernel: { logger_level: :warning },\n shop: { pool_size: 50 }\n }\n}bondy config generate --env prod applies base.bcl and then prod.bcl to the release. A patch overrides values. It does not unify with them, because with & a production value that differs from the release's would denote no value. Maps merge, and the patch replaces any other value.
Two consequences follow. The patch applies to the release's finished values, so the patched pool_size of 50 leaves timeout_ms at 10000. The default that reads pool_size does not run again. Also, the toolchain does not check a patch against Config when it generates the files. A patch that sets the port to 70000 produces a sys.config with port 70000.
The application can check its application environment when it starts:
\nmodule Shop.App implements Application(State = Null)\n\nimport Shop.Manifest.{type Config}\n\ntype State = Null\n\npublic function start(_start_type: Application.StartType, _args: Any) :: Application.StartResult ->\n let Ok(config) = Application.validate_env(:shop, Config)\n Shop.Sup.start_link(config)\n\npublic function stop(_state: State) :: Atom ->\n :okApplication.validate_env/2 unifies the application environment with Config and adds the defaults. With port 70000, it returns an error. The match on Ok(config) fails, start/2 crashes, and shop does not start.
Follow Config through the project. The manifest declares it, and the .app.src holds its defaults. The application's code imports it from Shop.Manifest. A release imports it from the same module, and the compiler checks the release against it. At start, the application checks its application environment against it again.
In an Erlang project, these are four places that each hold their own copy of the facts. In a Bondy project, they read one type.
\nThe type that validates explains shapes and unification in Bondy code. ↩︎
\nWhat a function is allowed to do explains how the compiler works out what a function can do. ↩︎
\nI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nA temperature sensor, a threshold, and an alarm. First attempt:
\ndef alarm_active?(reading), do: reading > 100.0It is wrong in a way that takes a week to notice. The reading crosses a hundred, the alarm goes active, an operator looks up, the reading dips to ninety-nine, and the alarm is gone. Nobody acknowledged it. Nothing recorded that it happened. Real alarms latch: they stay active from the crossing until someone clears them, whatever the reading does in between.
\nSecond attempt, the one everyone ships:
\ndef handle_info({:reading, r}, %{alarm: false} = s) when r > 100.0,\n do: {:noreply, %{s | alarm: true}}\n\ndef handle_info({:reading, _r}, s),\n do: {:noreply, s}\n\ndef handle_call(:ack, _from, s),\n do: {:reply, :ok, %{s | alarm: false}}Now it latches. And now three questions have no answer. Since when has the alarm been active? What crossed the threshold, and what was the reading? Was it active at 03:14 last Tuesday, when the incident report says the pump failed?
\nThe boolean holds the truth and throws away the time, the cause, and the history. You then spend the next day reconstructing them from log lines, if the log lines are there.
\nThe second post named the two ideas this needs: a role, the fluent, and a noun, the signal. This post shows what they look like in the design, and says plainly which parts exist.
\nA fluent is a statement whose truth changes only when a named event changes it, and which stays true or false in between. It is the latched alarm, with the time and the cause kept. In the design, a fluent is a constraint with an attribute, and the rules that change it use two built-in operations:
\n%% Design. Not in the compiler yet; see the roadmap.\n\ntype AlarmActive = {sensor: String}\n@fluent\nconstraint AlarmActive\n\nconstraint Crossed = {sensor: String, reading: Float}\nconstraint Acknowledged = {sensor: String}\n\nrule latch =\n on Crossed(sensor: s, reading: _) as c\n remove c\n tell initiate(AlarmActive(sensor: s))\n end\n\nrule clear =\n on Acknowledged(sensor: s) as a\n remove a\n tell terminate(AlarmActive(sensor: s))\n endRead it against the Elixir. Crossed is the occurrence: it is told to the store, a rule removes it, and the rule's body does not set anything. It initiates the fluent, which records that AlarmActive(sensor: s) holds from now, because of this crossing. Acknowledged is the other occurrence, and its rule terminates the fluent, which records that it stopped holding now, because of this acknowledgement.
Between the two, the fluent stays true on its own. A reading of ninety-nine is not an occurrence that terminates anything, so it changes nothing. That is the behaviour the first attempt got wrong and the second attempt got right by accident.
\nThe queries are where the three lost answers come back:
\n%% Design.\nholds(AlarmActive(sensor: \"t1\")) %% is it active now?\ninitiated_at(AlarmActive(sensor: \"t1\")) %% since when?\nholds_at(AlarmActive(sensor: \"t1\"), t) %% was it active at t?holds is the boolean you had. initiated_at is the timestamp you did not. holds_at is the historical query that the incident report needed, and it works because the design keeps terminated fluents in a history rather than deleting them.
Time here is logical, not wall-clock: a counter inside a process, and a hybrid logical clock between processes. That is a deliberate choice, and it is what keeps the fluent store deterministic without processes having to coordinate. "Expires in thirty seconds" becomes a checkpoint computed when the fluent starts, not a comparison against os:timestamp() in a guard. A guard must not read the clock for the same reason, as the post on effects explained.
The reading itself is the other idea. A temperature isn't a fact that holds or an event that happens. It's a value that is always current, comes from outside, and remembers nothing. That is a signal, and the compiler already accepts its declaration, though nothing runs behind it yet:
\n%% Design. The declarations compile; the engine is not built.\n\nconstraint Reading = {sensor: String, celsius: Float}\n\nsignal temperature := latest(Reading(sensor: \"t1\"))\nsignal too_hot := temperature > 100.0too_hot is the first attempt's boolean, and it is correct as a signal: true exactly when the reading is high, false the moment it is not, no inertia. The bug was never that expression. The bug was using it as the alarm. The crossing is the instant too_hot goes from false to true. In the design, that transition is what gets told to the store as Crossed, and there the fluent takes over.
So the whole scenario, with every noun and role in its place. The reading is a signal, and the threshold test is a signal over it. The crossing is an occurrence, told to the store. A rewrite rule matches it and initiates the fluent. An acknowledgement is another occurrence, and another rule terminates the fluent. Four nouns and roles, none of them standing in for another, and none of the three questions lost.
\nEverything shown as working in the earlier posts compiles on the current toolchain, and I have been careful to say so each time. Here is the same care in the other direction.
\nThe signal name := expr declaration compiles. There is no signal engine behind it: nothing recomputes, nothing is sampled. The @fluent attribute, initiate, terminate, holds, holds_at and the history log do not exist in the compiler. What they need is an extra step in the reactor: after each round of rules, update the fluents and recompute the signals. That step is designed and planned for version 0.9.
I am publishing the design now, before the code, for the reason the second post gave. These two are the ones whose absence you feel least, until you try to write the alarm. Everyone's first alarm clears itself. Everyone's second alarm forgets why it fired. The language that has both fluents and signals is the one where the third attempt is the first.
\nThe next post is the last in the series, and it is the whole rate limiter in one place.
\n", "url": "https://bondy.io/posts/2026-10-12-the-alarm-that-cleared-itself", "title": "The alarm that cleared itself", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language", "Fluents", "Signals" ] }, { "id": "https://bondy.io/posts/2026-10-12-what-a-function-is-allowed-to-do", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nHere is an Erlang spec:
\n-spec price(Order :: order()) -> integer().It tells you what goes in and what comes out. It does not tell you whether price/1 reads a config file or calls a pricing service over the network. Nor does it say whether it writes to an ETS cache, sends a message to a logger, or asks the clock what day it is. All of those are invisible in the signature. All of them change what you can safely do with it: call it twice, cache its result, run it on another node, or call it from inside a rule.
Erlang handles this for guards by limiting them to a fixed list of built-in functions, since the runtime can't know whether anything else has side effects. You can write when is_integer(X), X > 0 but not when valid_price(X). It's safe, and it means any non-trivial condition moves out of the guard and into the body.
Bondy keeps the safety and drops the restriction. The compiler works out what every function may do, and a guard can call any function it can show is harmless.
\nA capability is something a function may do beyond computing its result. The kinds include the file system, the network, ETS tables, the process dictionary, processes and their messages, the clock and random numbers. The compiler infers, for every function, the set of capabilities its body uses, including everything it calls. You write no annotations for this.
\nThat set is part of the function's type. A function type in Bondy is not only "takes Int, returns Int" but "takes Int, returns Int, and may do these things". Keeping it on the type, rather than in a side table, is what makes the next section work.
A function whose set is empty does nothing but compute. The compiler describes functions with a small vocabulary of laws:
\nf(f(x)) == f(x). Normalising data is the typical case, and so is unifying a value with a fixed shape: doing it again adds nothing.total is separate.idempotent and monotone both include deterministic, which includes pure. The compiler checks these two only for functions whose body it can analyse, such as a one-argument function that unifies its argument with a fixed shape. For anything else, you state them as a hint (below).
You can write a law down with @law, and the compiler checks it:
@law(:pure, :deterministic)\npublic function double(x: Int) :: Int -> \n x * 2\n\n@law(:pure)\npublic function shout(msg: String) :: String ->\n IO.println(msg)\n msgdouble compiles. shout does not:
Function shout/1 declares @law(:pure) \nbut the analysis cannot prove it: its inferred capability set \nis not empty. This is not a proof that the law is false: the \nanalysis is sufficient, not complete. Restructure the function into \nthe fragment the compiler recognises, or carry the law as \n@law(pure: :hint) to assert it untestedThe message is careful about what it knows. The analysis never calls something pure that is not, but it may fail to prove that something is pure when it is. When that happens and you know better, @law(pure: :hint) records the claim without the check, and the difference between checked and trusted stays visible in the code.
Reading the clock shows the difference between the first two laws. This function is pure, because it only reads the clock, but it is not deterministic:
\n@law(:pure)\npublic function now_ms() :: Int -> \n Time.system_time()That compiles. Declare it @law(:deterministic) instead and the compiler refuses: "its inferred capability set admits nondeterminism".
Back to the rules post. A rule's when guard runs while the engine decides which rule fires. If a guard wrote to a log, the log would depend on the order the engine tried rules in. If it read the clock, the same facts could fire different rules on different runs. So a guard can call your own functions, and the compiler requires them to be deterministic and to always return:
constraint Reading = {sensor: String, value: Int}\nevent Alarm = {sensor: String}\n\nfunction too_hot(v: Int) :: Bool -> \n v > 100\n\nrule alarm =\n on\n Reading(sensor: s, value: v) as r\n remove\n r\n when\n too_hot(v)\n tell\n Alarm(sensor: s)\n endtoo_hot has no annotations, and the rule compiles, because the compiler infers that too_hot does nothing but compare. Use a version with a debug print instead:
function too_hot_logged(v: Int) :: Bool ->\n IO.println(\"checking\")\n v > 100and the rule is rejected:
\nFunction too_hot_logged/1 is called \nfrom a CHR rule guard but is not verified as pure and deterministic. \nA guard is evaluated during rule matching, where an effect or a \nnondeterministic result changes which rules fire; CHR rule guards \nrequire @law(:deterministic) and @law(:total).The rule's body, its tell section, has no such restriction. It runs once the engine has decided, so it is the right place for effects.
Plenty of functions take other functions:
\npublic function twice(f: ((Int) :: Int), x: Int) :: Int -> \n f.(f.(x))Is twice pure? It depends entirely on f. A system that summarised each function with a single yes or no would have to answer "no", to be safe, and every caller of twice would inherit the "no". Because Bondy keeps capabilities on the function type, twice's type says instead that it does whatever f does. The answer is settled at each call:
@law(:pure, :deterministic)\npublic function quad(x: Int) :: Int -> \n twice(fun(y) -> y * 2 end, x)That compiles, and quad(3) is 12. Pass twice a function that prints, and the same @law line on the caller fails with law_not_verified. This is what lets functions that take functions be used inside guards and pure code without giving up the checks.
@law says what a function does not do. @capability says the most a function may do, as an upper limit the compiler holds the body to:
@capability(kind: :ets, mode: :read_write)\npublic function remember(table, key, value) ->\n Table.insert(table, (key, value))That compiles. Declare the same body as read-only:
\n@capability(kind: :ets, mode: :read)\npublic function sneaky(table, key, value) ->\n Table.insert(table, (key, value))and the body is caught writing:
\nFunction sneaky/3 declares @capability (ets, Atom, read), but its \nbody captures (ets, Atom, write), which the declaration does not \ncover. Widen the declaration to cover it, or compile with \n--laws=trust to assert the narrower declaration.The same attribute goes on an @external, a Bondy binding to an Erlang function, to say what the foreign code does. For Erlang functions the compiler already knows about, such as file:read_file/1, it checks your declaration against what it knows. For the rest, your declaration is what it trusts.
The compiler does not check capabilities at every call. Ordinary code calls whatever it likes, as it does in Erlang. The checks sit at the places where an effect would break a promise:
\n@law or a @capabilityEach of these asks the same question: are the capabilities of this function within what is allowed here? For guards and deterministic functions, the allowance is empty. A pure function is also allowed the clock and random numbers.
\nUntrusted code is the case this was built for. A compilation unit can be compiled in safe mode, with an explicit allowance: the capabilities the host grants it, for example "read and write ETS, nothing else". The compiler rejects a function that needs more. The unit also cannot declare its own laws, because code that is not trusted cannot vouch for itself. It is aimed at plugins, user-supplied logic, and code generated by tools rather than people. Today safe mode is an option of the compiler API, but there is no command-line switch for it yet.
\nThe capability kinds today are fairly coarse. A finer-grained ordering, where a grant for "this ETS table, read only" can stand in for a narrower request, is designed but not built. So are capabilities that can be handed from one process to another as values, scoped to a single interaction. I will write about both when they compile.
\nTwo choices shaped it.
\nInferred, not declared. You can write @law and @capability, but you never have to. Ordinary code carries no annotations, and the compiler still knows what every function may do. Annotations appear only where you want a promise enforced.
Tracked, not handled. Languages such as Koka treat effects as operations that handlers can intercept and redefine. Bondy does not. It tracks what a function may do and checks it where it matters. That is all the BEAM needs: processes, messages and supervisors already cover what effect handlers are usually used for.
\nWhat you get is a spec that finally includes the part the Erlang spec left out. The rest of the series leans on it. Rules can call your functions, queries always have one answer, and code you did not write can run with only the capabilities you granted it.
\n", "url": "https://bondy.io/posts/2026-10-12-what-a-function-is-allowed-to-do", "title": "What a function is allowed to do", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language", "Effects", "Capabilities", "Types" ] }, { "id": "https://bondy.io/posts/2026-10-12-ask-questions-of-your-data", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nEvery codebase has one of these. Who is in Alice's management chain? Which products can substitute for this one, directly or through a chain of substitutes? Which documents can this user reach through the groups they belong to? You write it as a recursive function over a list of pairs:
\n%% reports: [{Who, Boss}]\nmanages(Boss, Who, Reports) ->\n lists:member({Who, Boss}, Reports)\n orelse lists:any(\n fun({W, B}) ->\n W =:= Who andalso manages(Boss, B, Reports)\n end, \n Reports\n ).It works until the data has a cycle, and then it never returns. So you add a visited set:
\nmanages(Boss, Who, Reports) ->\n manages(Boss, [Who], Reports, sets:new()).\n\nmanages(_Boss, [], _Reports, _Seen) ->\n false;\nmanages(Boss, [W | Rest], Reports, Seen) ->\n case lists:member({W, Boss}, Reports) of\n true -> \n true;\n false ->\n Next = [\n B || {W1, B} <- Reports, W1 =:= W,\n not sets:is_element(B, Seen)\n ],\n manages(\n Boss, \n Next ++ Rest, \n Reports, \n sets:add_element(W, Seen)\n )\n end.Now it terminates. It is a depth-first search with an accumulator, written by hand. Yet the question it answers is one sentence long: B manages W if W reports to B, or W reports to someone B manages. The search order, the cycle protection and the accumulator are not part of the question. They are the price of asking it in a language whose only tool for "what follows from these facts" is a function that walks them.
\nThe second post called this the relation role. A relation holds facts, and you can ask about them in either direction: who Alice reports to, or who reports to Carol. Here it is, and every line compiles:
\nrelation ReportsTo = {who: String, boss: String}\n\nfact ReportsTo(who: \"alice\", boss: \"bob\")\nfact ReportsTo(who: \"bob\", boss: \"carol\")\n\nrelation Manages(boss: String, who: String) :-\n ReportsTo(who: who, boss: boss)\n\nrelation Manages(boss: String, who: String) :-\n ReportsTo(who: mid, boss: boss), \n Manages(boss: mid, who: who)relation ReportsTo = {...} declares what a fact looks like and makes it a relation. A fact declaration is static data written into the module: the facts the relation starts with. The next section shows how facts come and go while the program runs.
The two Manages lines are a derivation rule, the second kind of rule in Bondy. Read :- as "if". Bob manages Alice if Alice reports to Bob. Carol manages Alice if Alice reports to someone Carol manages. Two rules for the same relation mean "either one": Manages holds whenever either rule says so.
Then you ask:
\npublic function team_of(boss: String) ->\n query Manages(boss: boss, who: w) end\n\npublic function bosses_of(who: String) ->\n query Manages(boss: b, who: who) endteam_of returns every w the rules can reach. A field with a value is a filter, and a field left as a variable is what you want back. bosses_of asks the same relation the opposite question, everyone above a person, with no second traversal. With the two facts above:
team_of(\"carol\") => [{\"alice\"}, {\"bob\"}]\nbosses_of(\"alice\") => [{\"bob\"}, {\"carol\"}]Each answer is a tuple with one element per variable you left open.
\nA relation says what a fact looks like. It says nothing about where facts are kept. That is the job of a relation store: a supervised process that owns the storage for a set of relations. You declare one as a module implementing the Relation.Store behaviour, with four required callbacks:
module Org.Store implements Relation.Store\n\nimport Org.{relation ReportsTo}\n\npublic function name() :: Atom -> \n :org\n\npublic function adapter() :: Module -> \n Relation.Adapter.Table\n\npublic function opts() :: Map -> \n #{}\n\npublic function relations() :: List(TypeRef) -> \n [ReportsTo]adapter() picks the backend. Relation.Adapter.Table keeps the facts in ETS, in memory. Postgres.Relation.Adapter keeps them in PostgreSQL tables, with options such as the schema to use and whether to create the tables on start:
public function adapter() :: Module -> \n Postgres.Relation.Adapter\n\npublic function opts() :: Map ->\n #{\n :schema => \"public\", \n :ddl => :drop_and_create, \n :on_destroy => :drop\n }Moving between the two changes the store module and nothing else. The relations, the rules and the queries stay the same, because they never mentioned storage in the first place. You start a store with Relation.Store.start(Org.Store), which runs it under Bondy's own supervisor, or put Relation.Store.start_link/1 in your supervision tree. When it starts, it creates the storage and loads the relation's fact declarations into it.
From then on, facts come and go at runtime. You look up the relation's storage and insert or delete rows, each row built with the relation's constructor:
\nlet Ok(reports) = Relation.Registry.lookup(ReportsTo)\n\nRelation.Adapter.Table.insert(\n reports, \n ReportsTo(who: \"dee\", boss: \"carol\")\n)\n%% => Ok(:inserted)\n\nRelation.Adapter.Table.delete(\n reports, \n ReportsTo(who: \"alice\", boss: \"bob\")\n)\n%% => Ok({:deleted, ReportsTo(who: \"alice\", boss: \"bob\")})insert refuses a row of the wrong relation with Error(:wrong_relation), and delete returns Error(:not_found) for a row that is not there. The next query sees the change, derived relations included, because a query evaluates the rules over whatever the store holds at that moment. After the two calls above, team_of("carol") includes Dee, and Alice is no longer anyone's report.
There is no update. A fact is a statement that something is true. When it stops being true you delete it, and when something new becomes true you insert that. Changing Alice's manager is a delete of the old fact and an insert of the new one.
\nThe recursive Manages has no visited set because it does not need one. The engine evaluates derivation rules in rounds: start with the facts, apply every rule, add whatever is new, and repeat until a round adds nothing. Manages only recombines names that are already in the facts, so the rounds run out. A cycle in the data produces facts that already exist, so it adds nothing. Each round also only looks at what changed in the round before, so the engine doesn't redo work.
A rule that computes a new value in its body, such as n = m + 1, is different: it can add a new fact in every round. The compiler accepts it, and the engine stops it at a round limit with a fixpoint_diverged error.
That is what Seen did in the Erlang version, except you don't have to remember to write it. And the first Erlang version, the one that loops forever, can't be written at all.
Facts plus "if" rules, repeated until nothing new appears, is Datalog. It dates from 1977, and a lot of graph and policy engines run on it.
\nSometimes the question is about absence. Who has no manager? Which node has no outgoing edge?
\nrelation Node = {name: String}\nrelation Edge = {from: String, to: String}\n\nrelation Isolated(name: String) :-\n Node(name: name), \n not Edge(from: name, to: _)not Edge(...) succeeds when there is no matching fact. This is where "repeat until nothing changes" can go wrong. If A is defined as "not B" and B as "not A", each new A takes away a reason for a B, and the other way round. So the rounds never settle. Datalog handles this with stratification: a relation has to be fully computed before a rule can ask what is not in it. That excludes any relation that depends on its own absence.
I wrote the bad case to see what happens:
\nrelation A(name: String) :- \n Node(name: name), \n not B(name: name)\n\nrelation B(name: String) :- \n Node(name: name), \n not A(name: name)The compiler rejects it as unstratifiable and names the cycle: ['Bondy.Probe.B','Bondy.Probe.A']. It is the relation-side counterpart of the guard check on rewrite rules from two posts ago: a program that could not have a well-defined answer does not compile.
Access control is where most people meet this, because some part of the policy is always transitive. Users own resources. Admins can reach everything. A manager can reach what their reports own:
\nrelation User = {id: String, name: String, role: Atom}\nrelation Resource = {id: String, owner: String}\nrelation ReportsTo = {who: String, boss: String}\n\nrelation CanAccess(user: String, resource: String) :-\n Resource(id: resource, owner: user)\n\nrelation CanAccess(user: String, resource: String) :-\n User(id: user, role: :admin), \n Resource(id: resource)\n\nrelation Manages(boss: String, who: String) :-\n ReportsTo(who: who, boss: boss)\n\nrelation Manages(boss: String, who: String) :-\n ReportsTo(who: mid, boss: boss), \n Manages(boss: mid, who: who)\n\nrelation CanAccess(user: String, resource: String) :-\n Manages(boss: user, who: owner), \n Resource(id: resource, owner: owner)Five rules, each one a line from the policy document. The function version would be a can_access/2 with three branches, one calling the manages/3 from the top of this post, and next year a fourth branch for delegated access. Here that is one more rule.
The CanAccess rules also don't say which one to try first, when to stop, or what to cache. The engine decides that.
We have now seen both kinds of rule, so here they are side by side.
\nA derivation rule works over relations. It only adds facts, worked out from the ones already there. It never removes anything, so it finishes whenever its rules only recombine values already in the facts (stratification takes care of not). This is Datalog.
A rewrite rule works over constraints, the facts rules act on. It removes and replaces: a Bucket with three tokens becomes a Bucket with two, and the old one is gone. This is CHR. Because it can remove, the compiler has to check what Datalog gets for free, which is what the guard check in the rules post does.
Both match facts the same way. A ReportsTo in a relation and a Bucket in a constraint store are both values of a structural type. A rule matches either one by unification, the operation the third post shows in detail. You call neither kind of rule: both fire on their own. They do live in different stores, on purpose. Facts you look up and facts rules act on behave differently, so keeping them apart lets the compiler check each kind for what can go wrong with it.
That covers the roles that ship, and both kinds of rule. Before the roles that are still in design, one question the series has kept deferring: how does the compiler know a guard is pure? That is the next post.
\n", "url": "https://bondy.io/posts/2026-10-12-ask-questions-of-your-data", "title": "Ask questions of your data", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language", "Relations", "Datalog" ] }, { "id": "https://bondy.io/posts/2026-10-12-the-process-that-owns-the-store", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nThe rules in the last post had no process around them. That was deliberate, because the rules are the new part. But a store needs an owner, and on the BEAM the owner is a process.
\nIf you set out to write the limiter as a proper state machine on the BEAM, you would reach for gen_statem. It is OTP's behaviour for a process with named states and a clause for each event in each state. Bondy has it too, as GenStatem: the same behaviour, the same callbacks, with types. So that is the baseline for this post, written in Bondy.
Here is the limiter built the OTP way: one process per bucket, a supervisor to start them, and a registry (global) to find each bucket. The two Erlang tabs have the same module written with gen_statem, to compare line by line. One uses handle_event_function mode, as the Bondy version does. The other has a function per state (state_functions), the style an Erlang developer would more often reach for.
module Bucket implements GenStatem(State = Atom, Data = Tokens)\n\n@moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\"\n\nimport Kernel.Gen.{InitOk, NextStateActions, KeepStateActions}\nimport BucketSup\n\ntype Tokens = {tokens: Int, max: Int}\n\ntype Allowed = {remaining: Int}\ntype Refilled = {new_count: Int}\n\n%% --- API ------------------------------------\n\npublic function start_link(id: String, max: Int) ->\n GenStatem.start_link(name(id), __MODULE__, max, [])\n\npublic function create(id: String, max: Int) ->\n DynamicSupervisor.start_child(\n BucketSup, \n #{\n :id => id,\n :start => (__MODULE__, :start_link, [id, max])\n }\n )\n\npublic function request(id: String) ->\n call(id, :request)\n\npublic function refill(id: String, n: Int) ->\n call(id, (:refill, n))\n\nfunction name(id: String) -> \n (:via, :global, (__MODULE__, id))\n\nfunction call(id: String, msg) ->\n case rescue(fun() -> GenStatem.call(name(id), msg) end) of\n Ok(reply) -> \n reply\n Error(Exception(class: :exit, reason: (:noproc, _))) -> \n Error(:no_bucket)\n Error(e) -> \n exit(e.reason)\n end\n\n%% --- Callbacks -------------------------------------\n\npublic function callback_mode() -> \n :handle_event_function\n\npublic function init(max) ->\n InitOk(:available, Tokens(tokens: max, max: max))\n\n\npublic function handle_event((:call, from), :request, :available, d: Tokens) \n when d.tokens == 1 ->\n NextStateActions(\n :empty, \n Tokens(tokens: 0, max: d.max), \n [(:reply, from, Allowed(remaining: 0))]\n )\n\npublic function handle_event((:call, from), :request, :available, d: Tokens) ->\n let t = d.tokens - 1\n KeepStateActions(\n Tokens(tokens: t, max: d.max), \n [(:reply, from, Allowed(remaining: t))]\n )\n\npublic function handle_event((:call, from), (:refill, n), :available, d: Tokens) ->\n let t = min(d.tokens + n, d.max)\n KeepStateActions(\n Tokens(tokens: t, max: d.max), \n [(:reply, from, Refilled(new_count: t))]\n )\n\npublic function handle_event((:call, from), :request, :empty, _d) ->\n (:keep_state_and_data, [(:reply, from, :denied)])\n\npublic function handle_event((:call, from), (:refill, n), :empty, d: Tokens) when n > 0 ->\n let t = min(n, d.max)\n NextStateActions(\n :available, \n Tokens(tokens: t, max: d.max), \n [(:reply, from, Refilled(new_count: t))]\n )-module(bucket).\n-moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\".\n\n-behaviour(gen_statem).\n\n-export([create/2, request/1, refill/2]).\n-export([start_link/2, init/1, callback_mode/0, handle_event/4]).\n\n%% --- API ------------------------------------\n\nstart_link(Id, Max) ->\n gen_statem:start_link({via, global, {?MODULE, Id}}, ?MODULE, Max, []).\n\n\n%% One process per bucket, started under bucket_sup and found by id.\ncreate(Id, Max) -> \n supervisor:start_child(bucket_sup, [Id, Max]).\n\nrequest(Id) -> \n call(Id, request).\n\nrefill(Id, N) -> \n call(Id, {refill, N}).\n\ncall(Id, Msg) ->\n try gen_statem:call({via, global, {?MODULE, Id}}, Msg)\n catch exit:{noproc, _} -> {error, no_bucket}\n end.\n\n\n%% --- Callbacks -------------------------------------\ncallback_mode() -> \n handle_event_function.\n\ninit(Max) -> \n {ok, available, #{tokens => Max, max => Max}}.\n\n%% --- State Management-------------------------------\n\nhandle_event({call, From}, request, available, #{tokens := 1} = D) ->\n Reply = {reply, From, {allowed, 0}},\n {next_state, empty, D#{tokens := 0}, [Reply]};\n\nhandle_event({call, From}, request, available, #{tokens := T} = D) ->\n Reply = {reply, From, {allowed, T - 1}},\n {keep_state, D#{tokens := T - 1}, [Reply]};\n\nhandle_event({call, From}, {refill, N}, available, #{tokens := T, max := M} = D) ->\n T1 = min(T + N, M),\n Reply = {reply, From, {refilled, T1}},\n {keep_state, D#{tokens := T1}, [Reply]};\n\nhandle_event({call, From}, request, empty, _D) ->\n Reply = {reply, From, denied},\n {keep_state_and_data, [Reply]};\n\nhandle_event({call, From}, {refill, N}, empty, #{max := M} = D) when N > 0 ->\n T1 = min(N, M),\n Reply = {reply, From, {refilled, T1}},\n {next_state, available, D#{tokens := T1}, [Reply]}.-module(bucket).\n-moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\".\n\n-behaviour(gen_statem).\n\n-export([create/2, request/1, refill/2]).\n-export([start_link/2, init/1, callback_mode/0, available/3, empty/3]).\n\n%% --- API ------------------------------------\n\nstart_link(Id, Max) ->\n gen_statem:start_link({via, global, {?MODULE, Id}}, ?MODULE, Max, []).\n\n\n%% One process per bucket, started under bucket_sup and found by id.\ncreate(Id, Max) -> \n supervisor:start_child(bucket_sup, [Id, Max]).\n\nrequest(Id) -> \n call(Id, request).\n\nrefill(Id, N) -> \n call(Id, {refill, N}).\n\ncall(Id, Msg) ->\n try gen_statem:call({via, global, {?MODULE, Id}}, Msg)\n catch exit:{noproc, _} -> {error, no_bucket}\n end.\n\n\n%% --- Callbacks -------------------------------------\ncallback_mode() -> \n state_functions.\n\ninit(Max) -> \n {ok, available, #{tokens => Max, max => Max}}.\n\n%% --- State Management-------------------------------\n\navailable({call, From}, request, #{tokens := 1} = D) ->\n Reply = {reply, From, {allowed, 0}},\n {next_state, empty, D#{tokens := 0}, [Reply]};\n\navailable({call, From}, request, #{tokens := T} = D) ->\n Reply = {reply, From, {allowed, T - 1}},\n {keep_state, D#{tokens := T - 1}, [Reply]};\n\navailable({call, From}, {refill, N}, #{tokens := T, max := M} = D) ->\n T1 = min(T + N, M),\n Reply = {reply, From, {refilled, T1}},\n {keep_state, D#{tokens := T1}, [Reply]}.\n\nempty({call, From}, request, _D) ->\n Reply = {reply, From, denied},\n {keep_state_and_data, [Reply]};\n\nempty({call, From}, {refill, N}, #{max := M} = D) when N > 0 ->\n T1 = min(N, M),\n Reply = {reply, From, {refilled, T1}},\n {next_state, available, D#{tokens := T1}, [Reply]}.If you know gen_statem, everything is where you expect it. GenStatem.start_link and GenStatem.call are gen_statem:start_link and gen_statem:call, and the callbacks are callback_mode/0, init/1 and handle_event/4. A (:via, :global, …) name registers the process, and DynamicSupervisor starts one bucket per id. What Bondy adds is types. The data is a Tokens struct, the replies are typed values, and each transition is a typed constructor such as NextStateActions. Bondy has no try/catch, so rescue turns the exit from a bucket that does not exist into Error(:no_bucket) and lets any other exit through.
Run it: create a bucket with two tokens, request three times, refill by five, request once more, and then request a bucket that does not exist:
\n[\n Ok(<0.206.0>),\n Allowed(1),\n Allowed(0),\n :denied,\n Refilled(2),\n Allowed(1),\n Error(:no_bucket)\n]For one bucket this reads well. Its whole life is visible at a glance: available until it runs out, then empty, denying every request until a refill moves it back. That is what a state machine is for: one thing, a handful of named modes, and a clear answer for each event in each mode. Think of a connection that is connecting, connected or closing, or a door that is open, closed or locked.
This version runs one process per bucket, so it needs a supervisor to start them and a registry to find them. That is a choice about deployment, not a property of GenStatem: one GenStatem could as well hold every bucket in its data. For two states and two events, a GenStatem is hard to beat.
\nThe difference shows when the machine grows, and real limiters do. Premium buckets that are never denied. A daily spending cap on top of the token count. A bucket an operator has suspended. A throttled state after repeated denials.
\nIn a GenStatem each of these is a new state or a flag in the data. A new state needs a clause for every event it can receive, and every clause has to check a flag. The premium override has to appear in every state that can deny, and the cap has to appear in every clause that can allow. The logic is organised by state, so one sentence about the system gets copied into each state it applies to.
\nThen there is what you do when something worth knowing happens inside. It is a log call with the details flattened into a string, a callback module passed in at start, or a pg group you publish to. Three mechanisms for "something happened", none of them typed, each tied to a particular listener.
None of the OTP part is wasted. The process is the right unit. A store has an owner, the owner has a mailbox, the mailbox handles one message at a time, and the supervisor restarts the owner when it dies. Erlang got this right in 1986 and Bondy keeps it: every store is owned by one OTP process and settles inside that process. What changes is where the logic lives.
\nimplements checks One line of the code above deserves a closer look before moving on: the first. In Erlang, -behaviour(gen_statem) is a promise the compiler barely checks. Omit init/1 and erlc prints a warning and builds the module anyway. Return "denied" from a state function and it compiles cleanly, then crashes the state machine the first time that clause runs. (Both checked with OTP 29.)
In Bondy, implements is checked the way a type is. A behaviour is an ordinary module whose contract functions are marked @callback, each with a full type, plus abstract types: placeholders the behaviour leaves to whoever implements it. GenStatem has three, State, Data and Event. The implements line binds them for this module: GenStatem(State = Atom, Data = Tokens). Data and Event default to Any if left out. State has no default, so leaving it out is an error, and so is binding a name the behaviour does not declare.
The compiler then substitutes those bindings into every callback's type and checks the module's functions against the result:
\nhandle_event/4 missing is an error, not a warning. The optional ones (terminate/3, code_change/4, format_status/1) can be left out, as they are here.[1]init takes its argument unannotated: GenStatem.start_link can pass anything there, so init(max: Int) is rejected. A result can be narrower than the contract but never wider.Because Data = Tokens, "no more than the callback allows" means every transition in every clause must carry a Tokens. Write one clause that returns a plain map as the new data, and the module does not compile:
-- TYPE CHECK FAILED ---------------------------------\n\nI ran into a problem in your code:\n\ntype checking failed with 1 error\n\n --> lib/bucket.bondy:57:1\n |\n57 | public function handle_event((:call, from), :request, :available, d: Tokens) \n | ^ callback type mismatch for `handle_event/4`; expected: ((Atom | {Atom, {Pid, Any}}, Any, Atom, Bondy.Bucket.Tokens) :: Atom | {Atom, List(Any)} | Bondy.Kernel.Gen.KeepState | Bondy.Kernel.Gen.KeepStateActions | Bondy.Kernel.Gen.NextState | Bondy.Kernel.Gen.NextStateActions | Bondy.Kernel.Gen.Stop | Bondy.Kernel.Gen.StopAndReply); found: ((Any, Any, Any, Any) :: {keep_state_and_data, NonEmptyList({reply, {type_var,44,0,meta}, denied})} | Bondy.Kernel.Gen.KeepStateActions | Bondy.Kernel.Gen.NextStateActions); required by GenStatemThat is the benefit. A behaviour stops being a list of function names you hope you spelled right and becomes a contract the compiler holds you to. The mistake surfaces when you build, as an error pointing at the callback, not as a crash on whichever event first reaches the wrong clause. The implements line also documents the process: anyone reading it knows what its state is and what data it holds, before reading a single clause. And it is the same mechanism for every behaviour: GenServer, Supervisor, GenReactor below, and any behaviour you write yourself, an ordinary module with @callback functions.
GenReactor is Bondy's behaviour for a process whose state is a store of facts and whose logic is rules. Here is the same limiter as a GenReactor, every bucket in one process. It compiles on the current toolchain:
module RateLimiter implements GenReactor(Event = Allowed | Denied | Refilled)\n\n@moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\"\n\nimport GenReactor.{type Reply, NoReply}\n\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\nconstraint Refill = {id: String, amount: Int}\n\nevent Allowed = {id: String, remaining: Int}\nevent Denied = {id: String}\nevent Refilled = {id: String, new_count: Int}\n\n%% --- Rules--- ----------------------\n\nrule consume_token =\n on\n Request(id: rid) as req,\n Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove\n req, bucket\n when\n t > 0\n tell\n Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n end\n\nrule deny_when_empty =\n on\n Bucket(id: rid, tokens: 0),\n Request(id: rid) as req\n remove\n req\n tell\n Denied(id: rid)\n end\n\nrule refill_within_cap =\n on\n Refill(id: rid, amount: amt) as refill,\n Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove\n refill, bucket\n when\n t + amt =< m\n tell\n Bucket(id: rid, tokens: t + amt, max_tokens: m),\n Refilled(id: rid, new_count: t + amt)\n end\n\nrule refill_to_cap =\n on\n Refill(id: rid, amount: amt) as refill,\n Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove\n refill, bucket\n when\n t + amt > m\n tell\n Bucket(id: rid, tokens: m, max_tokens: m),\n Refilled(id: rid, new_count: m)\n end\n\n%% --- API ------------------------------------\n\npublic function start_link() ->\n GenReactor.start_link(__MODULE__, [], [])\n\npublic function start_link(name) ->\n GenReactor.start_link(__MODULE__, [], #{:name => name})\n\npublic function create_bucket(reactor, id, max_tokens) ->\n GenReactor.tell(reactor, Bucket(id: id, tokens: max_tokens, max_tokens: max_tokens))\n\npublic function request(reactor, id) ->\n GenReactor.tell(reactor, Request(id: id))\n\npublic function refill(reactor, id, amount) ->\n GenReactor.tell(reactor, Refill(id: id, amount: amount))\n\npublic function stop(reactor) ->\n GenReactor.stop(reactor)\n\n\n%% --- Callbacks -------------------------------------\n\npublic function init(_args) ->\n Ok([])\n\npublic function handle_event(Allowed() as v, _ctx) -> \n Reply(value: v)\n \npublic function handle_event(Denied() as v, _ctx) -> \n Reply(value: v)\n\npublic function handle_event(Refilled() as v, _ctx) -> \n Reply(value: v)\n\npublic function handle_event(_, _) -> \n NoReply()Read it top to bottom: three constraints, three events, four rules that connect them, then an API and two callbacks. The API is the interesting part, because of how little it does.
\nimplements GenReactor(Event = Allowed | Denied | Refilled) says what this process can say to the outside world. The union is the process's public vocabulary, and it is typed. Nothing else leaves.
init/1 returns the initial store, here empty. A store starts as a list of constraints, so a limiter with pre-provisioned buckets would return them here.
handle_event/2 is the one decision the process makes that the rules do not: which events the caller gets to hear. Reply(value: v) sends the event back to whoever added the fact that caused it. NoReply() drops it. Omit the catch-all clause and an event nobody handles crashes the process. That is the right default for a typed vocabulary: an event you forgot about is a bug, not something to drop quietly.
The API is one verb: tell, which means adding a fact to the store. GenReactor.tell/2 is the synchronous form: it waits until the rules have settled and the resulting event has come back. GenReactor.tell_request/2 tells the store a constraint and returns a request id at once, so you decide when to fetch the response. The one other verb is ask: GenReactor.ask queries the store without adding anything to it. There is no handle_call, because there is nothing to dispatch on. A fact arrives, the rules do what they do, the events come out.
Run it with the same steps as the GenStatem above: create a bucket with two tokens, request three times, then refill by five.
\n[Ok(Allowed(id: \"k\", remaining: 1)), Ok(Allowed(id: \"k\", remaining: 0)),\n Ok(Denied(\"k\")), Ok(Refilled(id: \"k\", new_count: 2))]The refill lands on refill_to_cap, because five more tokens would overflow a bucket that holds two.
This is where the event role from the second post stops being a definition and becomes a mechanism.
\nA constraint stays in the store until a rule removes it. An event is declared with event instead of constraint, and the difference is one thing: every time the rules settle, the events are swept out of the store. Allowed never piles up. It exists for as long as handle_event needs to see it, and then it is gone. That is what "it happened" means at runtime: a moment, not a state.
That makes the event the answer to the three mechanisms for "something happened" from the top of this post. It is typed, so the listener gets Allowed(id: "api-key-1", remaining: 2), not a log line. It is addressed to nobody in particular, so the same event can go back to the caller, go to a subscriber, or be ignored. The rule that emitted it neither knows nor cares. And it is checked like every other value, so the same type checker that checks a Bucket in a rule checks an Allowed in a handle_event clause.
The rule emits. The process decides who hears. The sweep keeps the two apart.
\nThe two versions organise the logic differently.
\nIn the GenStatem, the logic is organised by state: what available does with each event, what empty does with each event. That is the right shape when there are a few states and each event means something clear in each of them. The number of clauses grows roughly as states times events, which is nothing at two by two.
In the GenReactor, the logic is organised by sentence. The state is a set of facts, and a rule fires when a combination of facts matches it: this request, with that bucket, when it has tokens. "Empty" is not a state to keep in sync: it is a bucket with zero tokens, and a rule that cares says so in its pattern. A new requirement is a new rule next to the others. The premium flag from the previous post is one rule, not a clause added to every state that can deny. The rules grow with the number of things you need to say, not with states times events.
\nEverything else is the same for both. Each is a supervised OTP process. Each can run one per bucket, with a supervisor and a registry, or one for many buckets. A GenReactor holding every bucket is the same choice as a GenStatem holding a map of them. Either way you shard by id when a single mailbox becomes the bottleneck.
\n| \n | GenServer | \nGenStatem | \nGenReactor | \n
|---|---|---|---|
| State | \nany term you manage | \none named state, plus data | \na store of facts | \n
| Input | \ncall, cast, info | \ncall, cast, info, timeouts, per state | \ntell (and ask, to query the store) | \n
| Logic | \ncallback clauses | \nclauses per state and event | \nrules that fire when facts combine | \n
| Output | \nreplies and side effects | \nreplies and actions | \ntyped events, routed by handle_event | \n
| Fits | \na service with some state | \na few states, each event clear in each | \na machine that keeps growing, with rules that combine conditions | \n
None of them replaces the others, and Bondy has all three: a door is still best written as a state machine. Use a GenReactor when the question is not "what mode am I in?" but "what follows from everything I know?".
\nUnderneath, this is an OTP process. start_link returns a pid, the named form registers it, and it goes into a supervisor's child list like any other worker. When it crashes, the supervisor restarts it, init rebuilds the store, and the facts it had collected are gone. That is the same durability contract a GenStatem's data has, for the same reason. If a store must survive a restart, its facts go somewhere durable and init reloads them, which is what you do today.
It compiles to a standard .beam module named Bondy.RateLimiter, so you can call it from Erlang:
{ok, Pid} = 'Bondy.RateLimiter':start_link(),\n'Bondy.RateLimiter':create_bucket(Pid, <<\"api-key-1\">>, 3),\n'Bondy.RateLimiter':request(Pid, <<\"api-key-1\">>).\n%% => {ok,{'Bondy.RateLimiter.Allowed',<<\"api-key-1\">>,2}}The reply is {ok, Event}, with the event as a tagged tuple, because that is how a Bondy value built from a structural type looks at runtime.
Distribution is OTP distribution. Register the reactor globally, tell it something from another node, and the constraint crosses the wire like any other message. There is no Bondy-specific transport in this release. The Partisan layer that runs Bondy Connect in production is the next step, not something the compiler does today.
\nLook back at the GenStatem at the top. The process around the logic is the same: a supervisor, and a registry if you run one process per bucket. What changed is the inside. The clauses per state and event are gone, replaced by rules, and the rules are the part that grows when the system does. Each new requirement is one more sentence, not a clause in every state it touches. The logging calls, callback modules or pg groups you would add for "something happened" are replaced by a typed event union and one function that decides who hears.
Plain messages that are not facts, such as a socket's data, still have a place: a GenReactor can define an optional handle_info.
What you have is a supervised process whose state is a set of facts and whose logic is a set of sentences about those facts. That is the noun the BEAM already gives you, the process, doing the job it always did, with the state machine inside it written in the language that was missing.
\nThe store in this post holds constraints, and rules rewrite them. The next post is about the other kind of store: one that holds facts you look up rather than facts you impose. It also covers the other kind of rule, the one that runs over it.
\nThis is why the limiter uses :handle_event_function, one callback for every state, rather than :state_functions, one function per state, which an Erlang version would often use. Bondy accepts :state_functions at runtime, but its conformance check does not follow it yet. It still requires handle_event/4, so the module needs a placeholder that is never called. And it does not check the state functions themselves, because their names are the module's own rather than the behaviour's. A state function that returns a string compiles, and fails at runtime with bad_return_from_state_function, exactly as in Erlang. With :handle_event_function, every transition passes through the one callback the compiler checks. ↩︎
I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nThe rules in the last post had no process around them. That was deliberate, because the rules are the new part. But a store needs an owner, and on the BEAM the owner is a process.
\nIf you set out to write the limiter as a proper state machine on the BEAM, you would reach for gen_statem. It is OTP's behaviour for a process with named states and a clause for each event in each state. Bondy has it too, as GenStatem: the same behaviour, the same callbacks, with types. So that is the baseline for this post, written in Bondy.
Here is the limiter built the OTP way: one process per bucket, a supervisor to start them, and a registry (global) to find each bucket. The two Erlang tabs have the same module written with gen_statem, to compare line by line. One uses handle_event_function mode, as the Bondy version does. The other has a function per state (state_functions), the style an Erlang developer would more often reach for.
module Bucket implements GenStatem(State = Atom, Data = Tokens)\n\n@moduledoc \"\"\"\nA token bucket rate limiter.\n\"\"\"\n\nimport Kernel.Gen.{InitOk, NextStateActions, KeepStateActions}\nimport BucketSup\n\ntype Tokens = {tokens: Int, max: Int}\n\ntype Allowed = {remaining: Int}\ntype Refilled = {new_count: Int}\n\n%%I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nA token bucket rate limiter, as a gen_server. You have written this one, or its cousin:
\nhandle_call({request, Id}, _From, #{buckets := Bs} = State0) ->\n case maps:find(Id, Bs) of\n {ok, #{tokens := T} = B0} when T > 0 ->\n B = B0#{tokens := T - 1},\n State = State0#{buckets := Bs#{Id := B}},\n Reply = {allowed, T - 1},\n {reply, Reply, State};\n\n {ok, #{tokens := 0}} ->\n {reply, denied, State0};\n\n error ->\n {reply, {error, no_bucket}, State0}\n end;\n\nhandle_call({refill, Id, Amount}, _From, #{buckets := Bs} = State0) ->\n case maps:find(Id, Bs) of\n {ok, #{tokens := T, max := M} = B0} ->\n T1 = min(T + Amount, M),\n B = B0#{tokens := T1},\n Reply = {refilled, T1},\n State = State0#{buckets := Bs#{Id := B}},\n {reply, Reply, State};\n\n error ->\n {reply, {error, no_bucket}, State0}\n end.It is short, idiomatic, and it works, but where is the rule? "A request against a bucket that has tokens uses one up and is allowed" is one sentence. In the code it is spread across the message shape, the map lookup, the guard, the bucket update, the state update and the reply tuple. Add a second rule, "premium buckets are never denied", and count the clauses you have to touch. The logic is scattered because the language has no place for a sentence of the form when these things are together, do this to them. It only has functions, so the sentence dissolves into control flow.
\nThe second post said a rule runs when the world makes it true. Here is what that means in practice. The same limiter, in Bondy:
\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\n\nevent Allowed = {id: String, remaining: Int}\nevent Denied = {id: String}\n\nrule consume_token =\n on\n Request(id: rid) as req,\n Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove\n req, bucket\n when\n t > 0\n tell\n Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n end\n\nrule deny_when_empty =\n on\n Bucket(id: rid, tokens: 0),\n Request(id: rid) as req\n remove\n req\n tell\n Denied(id: rid)\n endThe first two lines declare two structural types and put them in the constraint role. So their values live in a store: a collection of facts the rules work on. The next two are events, which leave the store as soon as the rules are done with them.
\nThen come two rules, and each reads as one sentence. consume_token: on a Request and a Bucket with the same id, remove both when the bucket has tokens, and tell a bucket with one token fewer and an Allowed event. deny_when_empty: on a bucket with no tokens and a request made against it, remove the request and tell Denied.
Nobody calls a rule. You add Request(id: "api-key-1") to the store, and the store looks for rules whose left-hand side now matches, and fires them. It repeats until no rule matches any more. That end state is called the fixed point: the store has settled, and the events produced along the way are what the outside world sees.
Three pieces of syntax carry all of the meaning.
\non, as and remove say what happens to the facts a rule matched. on lists the patterns, as names a matched fact, and remove lists the named facts the rule takes out of the store. Every fact it does not remove stays. The bucket in deny_when_empty is kept, because denying a request does not change the bucket. The bucket in consume_token is removed, because a new one with a different count replaces it.
There is no update, only remove and add: tell adds facts. The compiler knows from its declaration whether each is a constraint, which stays in the store, or an event, which leaves once the store settles. This split between kept and removed facts comes from Constraint Handling Rules (CHR), a rule language from the logic programming world that Bondy builds on.
A variable that appears in two patterns is a join. rid appears in both Request and Bucket, so the rule only fires for a request and a bucket with the same id. This is the part a function cannot give you, because a function receives one input. A rule matches a combination of facts, and the engine finds the combination for you. In the Erlang version the join is maps:find(Id, Bs), but here it is a shared name. Matching a pattern like Bucket(id: rid, tokens: 0) against a fact in the store is the same unification the previous post showed on values.
when is a guard, and it must be pure. t > 0 is an ordinary boolean expression over the matched variables, and it can call functions. The compiler checks that every function a guard calls has no side effects, always gives the same answer for the same input, and always returns. Otherwise it rejects the rule. That keeps the choice of which rule fires a question about the store, never about the clock or the network. How the compiler knows what a function does is the subject of the post on effects.
"Premium buckets are never denied." In the gen_server this touches the {ok, #{tokens := 0}} clause, adds a field to the bucket map, and changes the guard on the first clause. In the store, it is one more field and one more rule:
constraint Bucket = {\n id: String, \n tokens: Int, \n max_tokens: Int, \n premium?: Bool = false\n}\n\n@priority(10)\nrule premium_always_allowed =\n on\n Bucket(id: rid, premium: true),\n Request(id: rid) as req\n remove\n req\n tell\n Allowed(id: rid, remaining: -1)\n endThe field defaults to false, so the existing rules, which build a Bucket without it, stay as they are. Without annotations, the engine tries rules in the order they are written. @priority(10) moves this rule ahead of the others, so a premium request never reaches deny_when_empty, wherever the rule sits in the file. What matters is that the new requirement arrived as one new rule next to the old ones, and nothing else changed.
A guard can also ask about the store as a whole. Say every allowed request leaves a Spent fact behind, and a bucket is exhausted once there are as many of them as its cap:
constraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Spent = {id: String, cost: Int}\nevent Exhausted = {id: String}\n\nrule exhausted =\n on\n Bucket(id: rid, max_tokens: cap)\n when\n count_if(Spent(id: rid)) >= cap\n tell\n Exhausted(id: rid)\n endcount_if counts every Spent in the store that matches the pattern. There are a few of these aggregates, among them count_if, exists, maxover and findall. They let a rule see the state of the world, not only the facts it matched. The gen_server equivalent is a fold over a map inside a guard, which means a helper function you write, name and test separately.
A rule is a declaration, not a block of control flow, so the compiler can inspect it before it runs. My first version of a spending cap was the obvious one: allow a request while fewer requests than the cap have been spent.
\nrule allow_under_cap =\n on\n Bucket(id: rid, max_tokens: cap),\n Request(id: rid) as req\n remove\n req\n when\n count_if(Spent(id: rid)) < cap\n tell\n Spent(id: rid),\n Allowed(id: rid)\n endThe compiler refused it:
\n-- TYPE CHECK FAILED ---------------------------------\n\nI ran into a problem in your code:\n\ntype checking failed with 1 error\n\nGuard of rule allow_under_cap is not monotone under store growth (verdict: anti_monotone), which would break confluence. Absence tests and anti-monotone comparators are not supported; encode the absence as a complementary constraintHere is what it means. Facts can arrive in any order: a request, then another request, then a refill, from different callers at the same time. A rule set is well behaved (the CHR term is confluent) when the store reaches the same state whatever that order was. A guard that can go from true to false as more facts arrive breaks this.
\ncount_if(…) < cap is true while few facts have been spent and becomes false as more arrive, so whether a request is allowed would depend on who got in first. So the compiler requires that once a guard is true, adding facts can't make it false. count_if(P) >= k passes, because more facts only keep it true. count_if(P) < k and count_if(P) == 0 don't.
"Encode the absence as a complementary constraint" is the fix, and you have already seen it. Instead of counting what has been spent and comparing against a cap, keep a count of what is left in the store and let rules change it. That is the tokens field of Bucket, and consume_token is the rule that uses it. The compiler pushed me back to the design that was right from the start.
The compiler does not yet prove that a rule set terminates[1]. The guard check is the part of that story that ships today, and I would rather say so than have you discover it. It also catches the common mistakes, with errors that name the rule. They are a remove of a name that no pattern binds with as, a name bound or removed twice, and a section written twice or out of order. The order is always on, remove, when, tell, end.
The handle_call at the top of this post is a rule engine written by hand. It has a store (the state map), a set of rules (the clauses), a matcher (the patterns and guards), and an update (the map syntax). Every gen_server whose state is a collection of things that interact is one of these, and in every one of them the rules are dissolved into the plumbing.
A rule store gives you the sentences back. The bucket, the request, the cap and the premium flag are facts. "A request with tokens available is allowed" is a rule. The engine does the matching, the ordering and the settling. What is left to write is the part of the gen_server that was never about the rules: who can add facts to the store, and who hears what comes out. That is a process, and it is the next post.
\nIt is work in progress and part of the roadmap. ↩︎
\nI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nA token bucket rate limiter, as a gen_server. You have written this one, or its cousin:
\nhandle_call({request, Id}, _From, #{buckets := Bs} = State0) ->\n case maps:find(Id, Bs) of\n {ok, #{tokens := T} = B0} when T > 0 ->\n B = B0#{tokens := T - 1},\n State = State0#{buckets := Bs#{Id := B}},\n Reply = {allowed, T - 1},\n {reply, Reply, State};\n\n {ok, #{tokens := 0}} ->\n {reply, denied, State0};\n\n error ->\n {reply, {error, no_bucket}, State0}\n end;\n\nhandle_call({refill, Id, Amount}, _From, #{buckets := Bs} = State0) ->\n case maps:find(Id, Bs) of\n {ok, #{tokens := T, max := M} = B0} ->\n T1 = min(T + Amount, M),\n B = B0#{tokens := T1},\n Reply = {refilled, T1},\n State = State0#{buckets := Bs#{Id := B}},\n {reply, Reply, State};\n\n error ->\n {reply, {error, no_bucket}, State0}\n end.It is short, idiomatic, and it works, but where is the rule? "A request against a bucket that has tokens uses one up and is allowed" is one sentence. In the code it is spread across the message shape, the map lookup, the guard, the bucket update, the state update and the reply tuple. Add a second rule, "premium buckets are never denied", and count the clauses you have to touch. The logic is scattered because the language has no place for a sentence of the form when these things are together, do this to them. It only has functions, so the sentence dissolves into control flow.
\nThe second post said a rule runs when the world makes it true. Here is what that means in practice. The same limiter, in Bondy:
\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\n\nevent Allowed = {id: String, remaining: Int}\nevent Denied = {id: String}\n\nrule consume_token =\n on\n Request(id: rid) as req,\n Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove\n req, bucket\n when\n t > 0\n tell\n Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n end\n\nrule deny_when_empty =\n on\n Bucket(id: rid, tokens: 0),\n Request(id: rid) as req\n remove\n req\n tell\n Denied(id: rid)\n endThe first two lines declare two structural types and put them in the constraint role. So their values live in a store: a collection of facts the rules work on. The next two are events, which leave the store as soon as the rules are done with them.
\nThen come two rules, and each reads as one sentence. consume_token: on a Request and a Bucket with the same id, remove both when the bucket has tokens, and tell a bucket with one token fewer and an Allowed event. deny_when_empty: on a bucket with no tokens and a request made against it, remove the request and tell Denied.
Nobody calls a rule. You add Request(id: "api-key-1") to the store, and the store looks for rules whose left-hand side now matches, and fires them. It repeats until no rule matches any more. That end state is called the fixed point: the store has settled, and the events produced along the way are what the outside world sees.
Three pieces of syntax carry all of the meaning.
\non, as and remove say what happens to the facts a rule matched. on lists the patterns, as names a matched fact, and remove lists the named facts the rule takes out of the store. Every fact it does not remove stays. The bucket in deny_when_empty is kept, because denying a request does not change the bucket. The bucket in consume_token is removed, because a new one with a different count replaces it.
There is no update, only remove and add: tell adds facts. The compiler knows from its declaration whether each is a constraint, which stays in the store, or an event, which leaves once the store settles. This split between kept and removed facts comes from Constraint Handling Rules (CHR), a rule language from the logic programming world that Bondy builds on.
A variable that appears in two patterns is a join. rid appears in both Request and Bucket, so the rule only fires for a request and a bucket with the same id. This is the part a function cannot give you, because a function receives one input. A rule matches a combination of facts, and the engine finds the combination for you. In the Erlang version the join is maps:find(Id, Bs), but here it is a shared name. Matching a pattern like Bucket(id: rid, tokens: 0) against a fact in the store is the same unification the previous post showed on values.
when is a guard, and it must be pure. t > 0 is an ordinary boolean expression over the matched variables, and it can call functions. The compiler checks that every function a guard calls has no side effects, always gives the same answer for the same input, and always returns. Otherwise it rejects the rule. That keeps the choice of which rule fires a question about the store, never about the clock or the network. How the compiler knows what a function does is the subject of the post on effects.
"Premium buckets are never denied." In the gen_server this touches the {ok, #{tokens := 0}} clause, adds a field to the bucket map, and changes the guard on the first clause. In the store, it is one more field and one more rule:
constraint Bucket = {\n id: String, \n tokens: Int, \n max_tokens: Int, \n premium?: Bool = false\n}\n\n@priority(10)\nrule premium_always_allowed =\n on\n Bucket(id: rid, premium: true),\n Request(id: rid) as req\n remove\n req\n tell\n Allowed(id: rid, remaining: -1)\n endThe field defaults to false, so the existing rules, which build a Bucket without it, stay as they are. Without annotations, the engine tries rules in the order they are written. @priority(10) moves this rule ahead of the others, so a premium request never reaches deny_when_empty, wherever the rule sits in the file. What matters is that the new requirement arrived as one new rule next to the old ones, and nothing else changed.
A guard can also ask about the store as a whole. Say every allowed request leaves a Spent fact behind, and a bucket is exhausted once there are as many of them as its cap:
constraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Spent = {id: String, cost: Int}\nevent Exhausted = {id: String}\n\nrule exhausted =\n on\n Bucket(id: rid, max_tokens: cap)\n when\n count_if(Spent(id: rid)) >= cap\n tell\n Exhausted(id: rid)\n endcount_if counts every Spent in the store that matches the pattern. There are a few of these aggregates, among them count_if, exists, maxover and findall. They let a rule see the state of the world, not only the facts it matched. The gen_server equivalent is a fold over a map inside a guard, which means a helper function you write, name and test separately.
A rule is a declaration, not a block of control flow, so the compiler can inspect it before it runs. My first version of a spending cap was the obvious one: allow a request while fewer requests than the cap have been spent.
\nrule allow_under_cap =\n on\n Bucket(id: rid, max_tokens: cap),\n Request(id: rid) as req\n remove\n req\n when\n count_if(Spent(id: rid)) < cap\n tell\n Spent(id: rid),\n Allowed(id: rid)\n endThe compiler refused it:
\n-- TYPE CHECK FAILEDI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nData validation is one of the most boring and error-prone (yet critical) jobs we do. It happens at the edges of our systems, where data arrives from a request, a config file or another service. It has to happen before the data means anything. Once the data is inside, code can trust it and not check it again.
\nHere is how that usually looks for a config record in Erlang:
\n-type config() :: #{\n max_tokens := pos_integer(),\n refill_rate := pos_integer()\n}.\n\n-spec new(map()) -> config().\n\nnew(#{max_tokens := Max, refill_rate := Rate} = M)\n when is_integer(Max), Max > 0, Max =< 10000,\n is_integer(Rate), Rate > 0 ->\n M;\nnew(_) ->\n error(badarg).Count the places the same fact lives. The -type says max_tokens is a positive integer, for Dialyzer[1]. The guard says it again, for the runtime. The ceiling of 10000 appears only in the guard, because the type spec cannot express it. So the type is now a rough summary of the guard rather than the truth.
And the whole thing covers one way of building a config. Add optional fields, or a config that arrives in pieces, and you write another function with another copy of the rules.
\nThe second post showed the other half of the problem: rules that relate two fields, like "a discount must not exceed a tenth of the total". They don't fit in any schema DSL, so they become control flow. This post covers both halves.
\nIn Bondy, a shape is a value that describes which values are allowed. These are all shapes:
\n| Expression | \nMeaning | \n
|---|---|
Int | \nan integer | \n
Int & >= 18 | \nintegers from 18 up | \n
:standard | :premium | \none of two atoms | \n
{name: String, age: Int & >= 0} | \na closed record | \n
{name: String, age: Int & >= 0, ...} | \nan open record allowing extra fields | \n
Int & >= 18 is a refinement: Int with a condition attached. The values are still plain integers. The condition only excludes some of them. Shapes with named fields, like the last two, are structural shapes. The others are atomic shapes. Both kinds work the same way everywhere below.
Shapes are ordinary values. You can bind one to a variable, return it from a function, and combine it with other shapes at runtime:
\npublic function adult_check(age) ->\n let adult = Int & >= 18\n age & adultadult_check(20) => 20\nadult_check(15) => Never([#{:code => :conflict,\n :message => \"Expected value >= 18, got 15\", ...}])The & in that function is the most important operator in the language, and it has a name.
Unification, written &, combines two descriptions of a value into one that satisfies both, or reports that no such value exists. You already use it every time you write a refinement: Int & >= 18 is the shape Int unified with the predicate >= 18.
What it does depends on what you give it, but the idea is always the same: keep everything both sides say, and fail if they disagree.
\nA value and a shape. The result is the value, if the shape allows it. This is validation:
\npublic function person_check(data: Map) ->\n data & {name: String, age: Int & > 0, ...}person_check(#{:name => \"Ann\", :age => 0})\n => Never([#{:code => :conflict, :message => \"Expected value > 0, got 0\",\n :path => [:age], ...}])The error says which field broke which rule. The ... makes the shape open: data can carry fields the shape does not mention.
Two shapes. The result is a shape that requires both. You can build requirements from pieces:
\npublic function merged(data: Any) ->\n let named = {name: String, ...}\n let aged = {age: Int & > 0, ...}\n data & (named & aged)merged(#{:name => \"Ann\", :age => 3}) => UnifiedStruct(anonymous){name: \"Ann\", age: 3}\nmerged(#{:name => 7, :age => 3})\n => Never([#{:code => :type_mismatch, :message => \"Expected 'String', got 7\",\n :path => [:name], ...}])Two values. The result merges them if they agree, and fails on the first key where they don't:
\n#{:a => 1} & #{:b => 2} => #{:a => 1, :b => 2}\n#{:a => 1} & #{:a => 2} => Never([#{:code => :value_conflict, :path => [:a], ...}])When the compiler can prove that no value satisfies both sides, it reports the conflict before anything runs. Writing 1 & 2 is a type error, "1 & 2 denotes no value". Two map literals that disagree, as above, are caught at runtime.
Data that is not complete yet. This is where unification earns its keep: it accepts data that is not complete yet. Give it a map that has a name but no age:
\npublic function known_so_far(data: Any) ->\n data & {name: String, age: Int & > 0, ...}The result is not an error. It is a value with name set and age still open: it records that an age must be a positive integer, but not which one. Unify it later with the rest of the data and it completes. Ask for a finished value too early, with require_concrete, and you get a precise answer instead of a crash:
Error(#{:code => :incomplete,\n :message => \"Value is not concrete: field `age` is not fully specified\", ...})That is how Bondy handles a form completed over several steps, or a config assembled from several files. You unify each piece in as it arrives, and a wrong piece fails at once with its path. The value is usable only once it is complete. There is one set of rules, not one validator per stage.
\nA failed unification produces a Never (the bottom type) value carrying the reasons, not an exception, so you decide what to do with it. The same operation appears across the language: matching a pattern in a function head is one-sided unification. So is matching a fact in a rule, which the next posts rely on.
A structural type is a structural shape with a name (a.k.a. brand):
\ntype Config = {\n max_tokens: Int & > 0 & =< 10000,\n refill_rate: Int & > 0\n}The name matters. It gives Config an identity: a plain map with the right keys is not a Config until you build one. A function that expects a Config does not accept a map. So the checks run in one place, when a value becomes a Config, and never again after that.
There are three ways to build one, and they differ in how much they check.
\n1. Config(...) checks everything. With a literal, the compiler does the check:
public function bad() :: Config ->\n Config(max_tokens: -3, refill_rate: 1)-- TYPE CHECK FAILED ---------------------------------\n |\n9 | Config(max_tokens: -3, refill_rate: 1)\n | ^ field max_tokens: a value of type -3 is not a value of the declared field type Int & > 0 & =< 10000With a value that only exists at runtime, the same predicate runs when the constructor is called:
\npublic function from_input(max_tokens: Int, refill_rate: Int) :: Config ->\n Config(max_tokens: max_tokens, refill_rate: refill_rate)from_input(-3, 5) => error: runtime — cannot construct Config: Expected value > 0, got -3 (field `max_tokens`)Look at the two snippets again. The refinement you wrote for the compiler is the one the runtime enforces.
\n2. construct(data, Config) checks without crashing. It takes a map from the outside world and returns Ok or Error, with the path of every field that failed:
construct(#{:max_tokens => 20000, :refill_rate => 5}, Config)\n => Error(#{:code => :construct_failed,\n :message => \"Unification failed\",\n :reasons => [#{:message => \"Expected value =< 10000, got 20000\",\n :path => [:max_tokens], ...}]})This is the one to use at the edge of your system.
\n3. Config!(...) trusts you. It builds the value and skips the runtime check: given a max_tokens of -3 that only exists at runtime, Config!(max_tokens: max_tokens, refill_rate: 5) returns Config(max_tokens: -3, refill_rate: 5). The compiler still refuses what it can see is wrong, such as a literal -3 or a String where an Int belongs. It does not demand proof of > 0. Use it for values you already know are good, which is most values once they are inside the system.
Fields can also say whether the data must supply them, and a string field can carry a pattern (=~):
type User = {\n name: String,\n age: Int & >= 0,\n email?: String & =~ \"^[^@\\\\s]+@[^@\\\\s]+$\", %% may be absent; checked when present\n tls!: Bool %% must be supplied by the caller\n}construct(#{:name => \"Ann\", :age => 30}, User)\n => Error(... \"Required field tls must be provided ...\" ...)\nconstruct(#{:name => \"Ann\", :age => 30, :tls => true}, User)\n => Ok(User(name: \"Ann\", age: 30, tls: true))\nconstruct(#{:name => \"Ann\", :age => 30, :tls => true, :email => \"ann\"}, User)\n => Error(... \"Value \\\"ann\\\" does not match pattern ...\" ... :path => [:email] ...)And a field can be computed from its siblings. The leading dot means "this value's field":
\ntype Invoice = {\n quantity: Int,\n unit_price: Float,\n subtotal: .unit_price * .quantity,\n tax: .subtotal * 0.1,\n total: .subtotal + .tax\n}Invoice(quantity: 3, unit_price: 10.0)\n => Invoice(quantity: 3, unit_price: 10.0, subtotal: 30.0, tax: 3.0, total: 33.0)The fields are computed in dependency order, from the fields you supply, so the arithmetic that used to sit in a constructor lives in the type.
\nThat leaves the rules from the second post, the ones no schema DSL could hold: the order line's new/1. A discount must not exceed a tenth of the total, and a total above 10000 needs an approver. In Bondy they go on the fields, with when:
%% Amounts are in pence.\ntype OrderLine = {\n price: Int & > 0,\n quantity: Int & > 0,\n total: .price * .quantity when .total =< 10000 or .approved_by !== null,\n discount: Int & >= 0 = 0 when .discount * 10 =< .total,\n approved_by?: String\n}The 10% rule is written as .discount * 10 =< .total: whole-number arithmetic, so the check never divides and needs no rounding policy. The approval rule sits on total, not on approved_by, because a when on an optional field runs only when the field is there. An absent approved_by reads as null. These are the results of construct on seven order lines, straight from the program:
| price × quantity | \ndiscount | \napproved_by | \ncase | \nresult | \n
|---|---|---|---|---|
| 100 × 3 | \n— | \n— | \nno discount given | \naccepted, with discount: 0 | \n
| 100 × 3 | \n30 | \n— | \nexactly 10% | \naccepted | \n
| 100 × 3 | \n31 | \n— | \n10% and a penny | \nrejected: the when rule fails at discount | \n
| 100 × 3 | \n-1 | \n— | \nnegative | \nrejected: "Expected value >= 0, got -1" at discount | \n
| 5000 × 2 | \n— | \n— | \ntotal of exactly 10000 | \naccepted | \n
| 5001 × 2 | \n— | \n— | \nlarge order, no approver | \nrejected: the when rule fails at total | \n
| 5001 × 2 | \n— | \n"ana" | \nlarge order, approved | \naccepted | \n
In an Ecto changeset these rules live on one write path, and hold only for values that pass through that function. A code path that skips the changeset skips the rules. Here they live on the type, so every OrderLine in the system satisfies them, whichever path built it.
A shape does not make checking free. It changes where the check lives and how often you write it.
\n1 & 2.Config!(...) skips the runtime check.You still pay for the checks the compiler cannot prove away. What changes is that you stop writing them by hand, and stop scattering them across every path that might forget one.
\nEverything in this post checks one value, in one direction: the data arrives, and the shape says yes or no. A when on a field sees the other fields of the same value and nothing else.
Real systems have rules that span many values: a request is allowed only while its bucket has tokens, an alarm clears only when someone acknowledges it. Those rules are not attached to a type. They watch a collection of values and act when a combination of them appears. That is the next noun, the rule, and the next post.
\nI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\nData validation is one of the most boring and error-prone (yet critical) jobs we do. It happens at the edges of our systems, where data arrives from a request, a config file or another service. It has to happen before the data means anything. Once the data is inside, code can trust it and not check it again.
\nHere is how that usually looks for a config record in Erlang:
\n-type config() :: #{\n max_tokens := pos_integer(),\n refill_rate := pos_integer()\n}.\n\n-spec new(map()) -> config().\n\nnew(#{max_tokens := Max, refill_rate := Rate} = M)\n when is_integer(Max), Max > 0, Max =< 10000,\n is_integer(Rate), Rate > 0 ->\n M;\nnew(_) ->\n error(badarg).Count the places the same fact lives. The -type says max_tokens is a positive integer, for Dialyzer[^Dialyzer]. The guard says it again, for the runtime. The ceiling of 10000 appears only in the guard, because the type spec cannot express it. So the type is now a rough summary of the guard rather than the truth.
And the whole thing covers one way of building a config. Add optional fields, or a config that arrives in pieces, and you write another function with another copy of the rules.
\nThe second post showed the other half of the problem: rules that relate two fields, like "a discount must not exceed a tenth of the total". They don't fit in any schema DSL, so they become control flow. This post covers both halves.
\nIn Bondy, a shape is a value that describes which values are allowed. These are all shapes:
\n|Expression|Meaning|\n|
\n", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language", "Shapes", "Types", "Validation" ] }, { "id": "https://bondy.io/posts/2026-10-12-one-noun-more-roles", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\n\n\nTo complect is to take two or more separate concepts and entangle them so tightly that you can no longer reason about or change one without risking the other.
\n
Rich Hickey, the creator of Clojure, revived this old word to name the root cause of software complexity. His point is that complexity doesn't come from size or age. It comes from tying together things that should have stayed apart. Every "we can't touch that without breaking something else" is one of those knots. His prescription is to keep separate things separate: plain maps and sets instead of objects, values instead of mutable state, components side by side instead of twisted together.
\nI think Rich is right, and I try to follow this. But there is a gap in it, and the gap is where most of the day-to-day pain in a real codebase lives.
\nIf your data is "just" maps and sets, then everything you know about that data has nowhere to live except in your code. A bare map is typed by convention and by hope. Suppose you want to say "this map must have a name and an age, and the age is a non-negative integer below 130". The moment you do, you have left the data model and entered procedure.
So we write validators. On a good day we reach for a declarative DSL: Ecto schemas and NimbleOptions in Elixir, babel and maps_utils in Erlang (at Leasight), JSON Schema, clojure.spec, malli. These are good tools. But each is a second language bolted onto the first, and each can say some of what you mean and not the rest. Here is where the declarative part stops:
-module(example).\n\n-export([spec/0]).\n-export([new/1]).\n\n%% What the DSL can say: shape and per-field type.\nspec() ->\n #{\n price => #{\n required => true, \n datatype => pos_integer\n },\n quantity => #{\n required => true, \n datatype => pos_integer\n },\n discount => #{\n required => false, \n datatype => non_neg_integer\n },\n approved_by => #{\n required => false, \n datatype => binary\n }\n }.\n\n%% What the DSL cannot say. Three constraints as declarative as the\n%% four above, written as control flow because the spec has no slot\n%% for them.\nnew(Map0) ->\n Map = maps_utils:validate(Map0, spec()),\n #{price := Price, quantity := Qty} = Map,\n\n Total = Price * Qty,\n %% Default to zero\n Discount = maps:get(discount, Map, 0),\n\n %% Cross-field: discount may not exceed 10% of the line.\n Discount =< Total div 10 orelse error({invalid, discount}),\n\n %% Conditional on a computed value: large orders need \n %% an approver.\n case Total > 10000 andalso not is_map_key(approved_by, Map) of\n true -> \n error({missing, approved_by});\n false -> \n ok\n end,\n Map.Read spec/0 and you learn the shape and the types. Read new/1 and you learn nothing until you execute it in your head. Then you learn that Total is derived, that discount is bounded by it, and that approved_by is required sometimes. The condition lives three lines away from the field. "Discount is at most a tenth of the total" is as much a rule about the data as pos_integer is. But the DSL only understands one field at a time, so anything that involves two fields becomes code.
We complected the constraints into the constructor. Not by choice. In a vocabulary of maps, sets and functions a value can only ever be one thing, a datum. "Discount is at most a tenth of the total" is not a datum and it is not a function. It is a statement about what must hold, and the language has nowhere to put one.
\nMy conclusion is that the language should let the noun it already has play more roles.
\nIn most languages a value is one thing: a datum in a variable, waiting to be passed to a function. But in every real program the same value lives other lives.
\nThat value is a fact that holds, a relation. It is an invariant that is imposed, a constraint. It is something that happened, an event. It is a truth that persists until something ends it, a fluent. These are not four data structures. They are four roles one typed value can play, each with its own semantics.
\nThe computation side is just as thin. There is one noun, the function, and one verb, call. Two definitions are missing beside it: the rule, which runs when the world makes it true, and the signal, which never runs at all because it always equals its definition.
\nFor almost every one of these concepts, there is an entire programming paradigm built by taking that single idea seriously and making it a primitive.[1] Each paradigm discovered one element, turned it into its entire world, and made the others awkward to use. I believe the working programmer needs them all—in the same program, at the same time. At least, I always have. When a language only supplies one or two, we are forced to awkwardly bolt the rest onto whatever tools are at hand.
\nThis is why I don't describe Bondy as multi-paradigm. It has one way to describe data, the shape, and one type system. You describe a kind of value once, as a named shape. Its roles are one-line declarations on top of it, and this compiles today:
\n%% The order line from new/1. Amounts are in pence.\ntype OrderLine = {\n price: Int & > 0,\n quantity: Int & > 0,\n total: .price * .quantity when .total =< 10000 or .approved_by !== null,\n discount: Int & >= 0 = 0 when .discount * 10 =< .total,\n approved_by?: String\n}\n\n%% Its two roles\nrelation OrderLine\nconstraint OrderLine\n\n%% A type and its role, declared together\nevent LineApproved = {line: OrderLine, by: String}Every rule from new/1 is in the type. total is computed from its siblings. discount defaults to zero and may not exceed a tenth of the total. A total above 10000 needs an approved_by. The when on a field can read the other fields of the same value, so a rule that relates two fields sits next to the fields it relates.
That is my answer to the obvious objection, that four roles and two nouns sounds like six little languages bolted onto a seventh. They are not bolted on, because they share the same values. An OrderLine in a query, an OrderLine in a rule and an OrderLine arriving at the boundary are the same typed value, checked by the same type checker.
It also fits Hickey's own line between simple (not tangled up) and easy (familiar). A language where a value can only play one role makes you tangle the others into your code. That is complex in his sense, even with fewer keywords. A few separate roles, each doing one thing, is simpler, even if there is more to learn.
\nAlan Perlis’ famous epigram states that "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures". There is still one data structure here. What multiplies is what it is allowed to mean.
\nThree words I'll lean on. A noun is a kind of thing you can declare and name. A verb is an operation only that thing supports. A role is what a value is doing at runtime.
\nA shape answers one question: which values are allowed? Int is a shape. So is Int & >= 18, the integers from 18 up, and so is {name: String, age: Int & >= 0}, a record with two fields. A shape with named fields is a structural shape, and when you give one a name, as in type Person = {...}, you get a structural type.
Shapes are values in their own right. You can bind one to a variable, pass it around, and combine it with others at runtime:
\nlet adult = Int & >= 18\nage & adult %% the age if it is 18 or more; a failure saying why, if notThe & is unification: it combines two descriptions into one that satisfies both, or reports that they conflict. Int & >= 18 is itself a unification, of Int with >= 18. Unify a value with a shape and you have validation. Unify two shapes and you have a stricter shape. Unify data that is only half there and you get a value that knows which fields are still missing. The third post shows each of these running.
What makes "object" a slur in Hickey's vocabulary is not the record but everything OO added to it: identity, mutable state behind that identity, behaviour dispatched through it. Keep the record, throw the rest overboard, and you have what a bare map cannot give you: a description of which values are allowed, with the rules inside it. discount: Int & >= 0 = 0 when .discount * 10 =< .total is part of the type, not a check performed downstream. That settles the gap inside one value. It does not settle what must hold between values, or what follows when it does. That takes roles.
A relation answers: how are things connected? It is Codd's relational model, the one under every SQL database and Datalog. A value on its own describes one thing. A value in the relation role is a fact, and a set of facts describes how things are connected, which you can query and join.
\nWhat it replaces in your code is the object graph. order.customer and customer.orders are the same connection stored twice, kept in sync by hope, and each only works in one direction. A relation stores the connection once, and you query it from either side.
Its verbs are Codd's: select, project, join, insert, delete. There is no update. Update is delete-then-insert, and pretending otherwise is how the object graph smuggled mutation back in.
\nA constraint answers: what must hold? A relation is a set of facts you consult. A constraint is a fact you impose: you tell it to a store, and the store is then obliged to keep it consistent with everything else it has been told.
\nInside one value, the shape already holds what fell off the edge of the validation DSL and landed in new/1. A constraint takes the same idea across values. The invariant still lives with the type, not in a procedure the next reader has to execute in their head. And a constraint is not only something to check after the fact. Other facts can be derived from it: if the store knows age >= 0 and learns age = x - 1, it follows that x >= 1.
In Bondy, rules over the store are how you say what follows. Validation is the simplest case, where you already have all the values and only ask yes or no.
\nIts verbs are tell and ask: tell adds a constraint to the store, ask checks whether what the store knows already implies one. A schema has one verb, validate, and validate is tell-everything-then-ask-once. A constraint you can only validate has most of its meaning cut off.
\nThe natural objection, "isn't a constraint just a rule?", draws the line. A constraint is what must be true. A rule is when this, then that. One is a role a value plays. The other is a noun, and it gets its own section.
\nAn event answers: what happened? It has an instant, not a duration. It is never updated and never retracted, because it already happened.
\nWhat it replaces is the callback and the log line. In most languages "something happened" is either a function call or a string in a log. The call welds the occurrence to whoever is listening, and the log line keeps the occurrence but throws away its type. An event keeps both: a typed value, addressed to nobody in particular. In Bondy, events are what rules emit and what processes act on. What comes in is told to the store as a constraint, and what goes out is an event.
\nAn event has no inertia at all. The next role is nothing but inertia.
\nA fluent answers: what is true now, and since when? The idea comes from the event calculus: a fluent becomes true when something starts it and stays true until something ends it. "The light is on" becomes true when someone flips the switch and stays true until someone flips it back.
\nThe example that shows why this is its own role is an alarm. Define "alarm is active" as temperature > 100 and the alarm clears itself the instant the reading dips under the threshold. Real alarms latch. The alarm is initiated by the crossing, terminated by an acknowledgement, and in between it holds regardless of what the temperature does. That is what a mutable boolean throws away. The boolean has no record of when it changed or what changed it, and you spend the rest of the project reconstructing that from logs.
The query is holds-at: was this true at time t? Nothing sets a fluent. The only way to change one is to name what changed it.
\nFluents are designed and on the roadmap. The post on time covers the design.
\nA signal answers: what value does this always equal? The cleanest intuition is a spreadsheet cell. B1 = A1 * 2 is a signal. You never assign to B1: it always equals twice A1, and keeping that true is not your problem. Its verbs are define and sample. There is no set, because B1 = A1 * 2 would be meaningless if anyone could write to B1.
A signal is not a role, because it is not a fact playing a part. A signal is a definition, like a function. A function is a computation you call. A signal is a computation you never call, because its answer is already there.
\nThe alarm shows why fluents and signals are two things. The temperature is a signal: it always has a current value, computed from the sensor, and it keeps no history. "Temperature exceeds 100" is a signal too: it is true while the reading is above 100 and false as soon as it is not. The moment the reading goes above 100 is an event: it happens once, at one point in time. The latched alarm is a fluent: that event makes it true, and it stays true until someone acknowledges it, even after the temperature falls. Defining the alarm as temperature > 100 treats all four as one signal, and that is why it clears itself.
Signals are designed alongside fluents, on the same incremental engine.
\nA rule answers: what follows, and what reacts? It has two kinds, one for relations and one for constraints.
\nDerivation rules work over relations: they work out new facts from existing ones, until nothing new appears. This is Datalog, and it ships:
\nrelation Edge = {from: String, to: String}\n\nrelation Reachable(src: String, dst: String) :-\n Edge(from: src, to: dst)\n\nrelation Reachable(src: String, dst: String) :-\n Edge(from: src, to: mid), Reachable(src: mid, dst: dst)Rewrite rules work over constraints: they match several facts in a store at once, check a condition, and replace what they matched. This is CHR, Constraint Handling Rules, and it ships too. A rule matches facts with on, takes the ones it names out of the store with remove, and adds constraints and events with tell. The facts it does not remove stay in the store.
\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\nevent Allowed = {id: String, remaining: Int}\n\nrule consume_token =\n on Request(id: rid) as req, Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove req, bucket\n when t > 0\n tell Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n endMatching several facts at once is what a function can't do. You call a function with its input. A rule matches a combination of facts in the store (rid in both patterns is a join), and the engine decides when it fires.
\n\nA function runs when called. A rule runs when the world makes it true.
\n
Because a rule is a declaration and not control flow, the compiler can inspect it. Today it checks that every guard has no side effects and always gives the same answer. It also checks that a guard cannot go from true to false as more facts arrive, so the order of arrival cannot change the result. Checking that a rule set always terminates is on the roadmap.
\nRun the alarm once more, end to end. The temperature is a signal. When it crosses the threshold, the crossing is told to the store. A rewrite rule matches it, latches the alarm fluent, and emits an event so the rest of the system hears about it. When an acknowledgement arrives, another rule terminates the fluent. Four roles and two nouns, none standing in for another.
\nPut them side by side and the table is clean enough that I take it as evidence these are real, not invented:
\n| Noun or role | \nThe question it answers | \nIts verbs | \nWhat it separates | \n
|---|---|---|---|
| Shape (the noun) | \nWhich values are allowed? | \nunify (&) | \nThe description of a value from identity, state and behaviour | \n
| as relation | \nHow are things connected? | \nselect, project, join, insert, delete | \nA connection from the one direction you happened to store it in | \n
| as constraint | \nWhat must hold? | \ntell, ask | \nValidity from the procedure that checks it | \n
| as event | \nWhat happened? | \nemit, on | \nAn occurrence from whoever is listening | \n
| as fluent | \nWhat is true now, and since when? | \ninitiate, terminate, holds-at | \nA persistent truth from its cell and its cause | \n
| Signal | \nWhat value does this always equal? | \ndefine, sample | \nA derived value from the glue that recomputes it | \n
| Rule | \nWhat follows, and what reacts? | \nmatch, remove, derive, fire | \nDerivation and reaction from hand-wired control flow | \n
Unification belongs to the shape, and because every role is played by values of a shape, it works in all of them. It is what holds the table together: it is how a rule matches a constraint in the store and how a query matches a fact in a relation.
\nEverything else is specific. Nothing is joined except a relation. Nothing is told except a constraint. Nothing fires except a rule. And none of the verbs is assign.
\nRich is right that complecting is the disease and that maps and sets beat the object soup they replaced. My one amendment is that maps and sets answer one of these seven questions, what is this value. Offering them as the answer to all seven is itself a complecting. You get one role and one verb, and every other life a value leads gets smeared across procedures, DSLs and mutable cells. A language that ignores relation, constraint, event, fluent, signal and rule doesn't spare you those concepts. It makes you pay for them by hand, forever, with assign.
\nI've spent the last few years putting these under one type system, on the BEAM. Shapes, relations, constraints, events and both kinds of rule are in the compiler today. Fluents and signals are designed and come next. The rest of this series takes them one at a time, with code you can compile. It starts with shapes, and with how the compiler and the runtime check the order line above.
\nThe relational model and Datalog took the relation. Constraint programming took the constraint, and concurrent constraint programming (Saraswat) gave it tell and ask. The situation and event calculi (McCarthy and Hayes, then Kowalski and Sergot) took the event and the fluent. Logic programming took the rule. Synchronous and reactive languages (Lustre, Esterel, FRP) took the signal. Object orientation took the shape of the value and welded identity, state and behaviour onto it. ↩︎
\nI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative language for the BEAM: statically typed, functional, relational and rule-based.
\n\n\nTo complect is to take two or more separate concepts and entangle them so tightly that you can no longer reason about or change one without risking the other.
\n
Rich Hickey, the creator of Clojure, revived this old word to name the root cause of software complexity. His point is that complexity doesn't come from size or age. It comes from tying together things that should have stayed apart. Every "we can't touch that without breaking something else" is one of those knots. His prescription is to keep separate things separate: plain maps and sets instead of objects, values instead of mutable state, components side by side instead of twisted together.
\nI think Rich is right, and I try to follow this. But there is a gap in it, and the gap is where most of the day-to-day pain in a real codebase lives.
\nIf your data is "just" maps and sets, then everything you know about that data has nowhere to live except in your code. A bare map is typed by convention and by hope. Suppose you want to say "this map must have a name and an age, and the age is a non-negative integer below 130". The moment you do, you have left the data model and entered procedure.
So we write validators. On a good day we reach for a declarative DSL: Ecto schemas and NimbleOptions in Elixir, babel and maps_utils in Erlang (at Leasight), JSON Schema, clojure.spec, malli. These are good tools. But each is a second language bolted onto the first, and each can say some of what you mean and not the rest. Here is where the declarative part stops:
-module(example).\n\n-export([spec/0]).\n-export([new/1]).\n\n%% What the DSL can say: shape and per-field type.\nspec() ->\n #{\n price => #{\n required => true, \n datatype => pos_integer\n },\n quantity => #{\n required => true, \n datatype => pos_integer\n },\n discount => #{\n required => false, \n datatype => non_neg_integer\n },\n approved_by => #{\n required => false, \n datatype => binary\n }\n }.\n\n%% What the DSL cannot say. Three constraints as declarative as the\n%% four above, written as control flow because the spec has no slot\n%% for them.\nnew(Map0) ->\n Map = maps_utils:validate(Map0, spec()),\n #{price := Price, quantity := Qty} = Map,\n\n Total = Price * Qty,\n %% Default to zero\n Discount = maps:get(discount, Map, 0),\n\n %% Cross-field: discount may not exceed 10% of the line.\n Discount =< Total div 10 orelse error({invalid, discount}),\n\n %% Conditional on a computed value: large orders need \n %% an approver.\n case Total > 10000 andalso not is_map_key(approved_by, Map) of\n true -> \n error({missing, approved_by});\n false -> \n ok\n end,\n Map.Read spec/0 and you learn the shape and the types. Read new/1 and you learn nothing until you execute it in your head. Then you learn that Total is derived, that discount is bounded by it, and that approved_by is required sometimes. The condition lives three lines away from the field. "Discount is at most a tenth of the total" is as much a rule about the data as pos_integer is. But the DSL only understands one field at a time, so anything that involves two fields becomes code.
We complected the constraints into the constructor. Not by choice. In a vocabulary of maps, sets and functions a value can only ever be one thing, a datum. "Discount is at most a tenth of the total" is not a datum and it is not a function. It is a statement about what must hold, and the language has nowhere to put one.
\nMy conclusion is that the language should let the noun it already has play more roles.
\nIn most languages a value is one thing: a datum in a variable, waiting to be passed to a function. But in every real program the same value lives other lives.
\nThat value is a fact that holds, a relation. It is an invariant that is imposed, a constraint. It is something that happened, an event. It is a truth that persists until something ends it, a fluent. These are not four data structures. They are four roles one typed value can play, each with its own semantics.
\nThe computation side is just as thin. There is one noun, the function, and one verb, call. Two definitions are missing beside it: the rule, which runs when the world makes it true, and the signal, which never runs at all because it always equals its definition.
\nFor almost every one of these concepts, there is an entire programming paradigm built by taking that single idea seriously and making it a primitive.[^lineage] Each paradigm discovered one element, turned it into its entire world, and made the others awkward to use. I believe the working programmer needs them all—in the same program, at the same time. At least, I always have. When a language only supplies one or two, we are forced to awkwardly bolt the rest onto whatever tools are at hand.
\nThis is why I don't describe Bondy as multi-paradigm. It has one way to describe data, the shape, and one type system. You describe a kind of value once, as a named shape. Its roles are one-line declarations on top of it, and this compiles today:
\n%% The order line from new/1. Amounts are in pence.\ntype OrderLine = {\n price: Int & > 0,\n quantity: Int & > 0,\n total: .price * .quantity when .total =< 10000 or .approved_by !== null,\n discount: Int & >= 0 = 0 when .discount * 10 =< .total,\n approved_by?: String\n}\n\n%% Its two roles\nrelation OrderLine\nconstraint OrderLine\n\n%% A type and its role, declared together\nevent LineApproved = {line: OrderLine, by: String}Every rule from new/1 is in the type. total is computed from its siblings. discount defaults to zero and may not exceed a tenth of the total. A total above 10000 needs an approved_by. The when on a field can read the other fields of the same value, so a rule that relates two fields sits next to the fields it relates.
That is my answer to the obvious objection, that four roles and two nouns sounds like six little languages bolted onto a seventh. They are not bolted on, because they share the same values. An OrderLine in a query, an OrderLine in a rule and an OrderLine arriving at the boundary are the same typed value, checked by the same type checker.
It also fits Hickey's own line between simple (not tangled up) and easy (familiar). A language where a value can only play one role makes you tangle the others into your code. That is complex in his sense, even with fewer keywords. A few separate roles, each doing one thing, is simpler, even if there is more to learn.
\nAlan Perlis’ famous epigram states that "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures". There is still one data structure here. What multiplies is what it is allowed to mean.
\nThree words I'll lean on. A noun is a kind of thing you can declare and name. A verb is an operation only that thing supports. A role is what a value is doing at runtime.
\nA shape answers one question: which values are allowed? Int is a shape. So is Int & >= 18, the integers from 18 up, and so is {name: String, age: Int & >= 0}, a record with two fields. A shape with named fields is a structural shape, and when you give one a name, as in type Person = {...}, you get a structural type.
Shapes are values in their own right. You can bind one to a variable, pass it around, and combine it with others at runtime:
\nlet adult = Int & >= 18\nage & adult %% the age if it is 18 or more; a failure saying why, if notThe & is unification: it combines two descriptions into one that satisfies both, or reports that they conflict. Int & >= 18 is itself a unification, of Int with >= 18. Unify a value with a shape and you have validation. Unify two shapes and you have a stricter shape. Unify data that is only half there and you get a value that knows which fields are still missing. The third post shows each of these running.
What makes "object" a slur in Hickey's vocabulary is not the record but everything OO added to it: identity, mutable state behind that identity, behaviour dispatched through it. Keep the record, throw the rest overboard, and you have what a bare map cannot give you: a description of which values are allowed, with the rules inside it. discount: Int & >= 0 = 0 when .discount * 10 =< .total is part of the type, not a check performed downstream. That settles the gap inside one value. It does not settle what must hold between values, or what follows when it does. That takes roles.
A relation answers: how are things connected? It is Codd's relational model, the one under every SQL database and Datalog. A value on its own describes one thing. A value in the relation role is a fact, and a set of facts describes how things are connected, which you can query and join.
\nWhat it replaces in your code is the object graph. order.customer and customer.orders are the same connection stored twice, kept in sync by hope, and each only works in one direction. A relation stores the connection once, and you query it from either side.
Its verbs are Codd's: select, project, join, insert, delete. There is no update. Update is delete-then-insert, and pretending otherwise is how the object graph smuggled mutation back in.
\nA constraint answers: what must hold? A relation is a set of facts you consult. A constraint is a fact you impose: you tell it to a store, and the store is then obliged to keep it consistent with everything else it has been told.
\nInside one value, the shape already holds what fell off the edge of the validation DSL and landed in new/1. A constraint takes the same idea across values. The invariant still lives with the type, not in a procedure the next reader has to execute in their head. And a constraint is not only something to check after the fact. Other facts can be derived from it: if the store knows age >= 0 and learns age = x - 1, it follows that x >= 1.
In Bondy, rules over the store are how you say what follows. Validation is the simplest case, where you already have all the values and only ask yes or no.
\nIts verbs are tell and ask: tell adds a constraint to the store, ask checks whether what the store knows already implies one. A schema has one verb, validate, and validate is tell-everything-then-ask-once. A constraint you can only validate has most of its meaning cut off.
\nThe natural objection, "isn't a constraint just a rule?", draws the line. A constraint is what must be true. A rule is when this, then that. One is a role a value plays. The other is a noun, and it gets its own section.
\nAn event answers: what happened? It has an instant, not a duration. It is never updated and never retracted, because it already happened.
\nWhat it replaces is the callback and the log line. In most languages "something happened" is either a function call or a string in a log. The call welds the occurrence to whoever is listening, and the log line keeps the occurrence but throws away its type. An event keeps both: a typed value, addressed to nobody in particular. In Bondy, events are what rules emit and what processes act on. What comes in is told to the store as a constraint, and what goes out is an event.
\nAn event has no inertia at all. The next role is nothing but inertia.
\nA fluent answers: what is true now, and since when? The idea comes from the event calculus: a fluent becomes true when something starts it and stays true until something ends it. "The light is on" becomes true when someone flips the switch and stays true until someone flips it back.
\nThe example that shows why this is its own role is an alarm. Define "alarm is active" as temperature > 100 and the alarm clears itself the instant the reading dips under the threshold. Real alarms latch. The alarm is initiated by the crossing, terminated by an acknowledgement, and in between it holds regardless of what the temperature does. That is what a mutable boolean throws away. The boolean has no record of when it changed or what changed it, and you spend the rest of the project reconstructing that from logs.
The query is holds-at: was this true at time t? Nothing sets a fluent. The only way to change one is to name what changed it.
\nFluents are designed and on the roadmap. The post on time covers the design.
\nA signal answers: what value does this always equal? The cleanest intuition is a spreadsheet cell. B1 = A1 * 2 is a signal. You never assign to B1: it always equals twice A1, and keeping that true is not your problem. Its verbs are define and sample. There is no set, because B1 = A1 * 2 would be meaningless if anyone could write to B1.
A signal is not a role, because it is not a fact playing a part. A signal is a definition, like a function. A function is a computation you call. A signal is a computation you never call, because its answer is already there.
\nThe alarm shows why fluents and signals are two things. The temperature is a signal: it always has a current value, computed from the sensor, and it keeps no history. "Temperature exceeds 100" is a signal too: it is true while the reading is above 100 and false as soon as it is not. The moment the reading goes above 100 is an event: it happens once, at one point in time. The latched alarm is a fluent: that event makes it true, and it stays true until someone acknowledges it, even after the temperature falls. Defining the alarm as temperature > 100 treats all four as one signal, and that is why it clears itself.
Signals are designed alongside fluents, on the same incremental engine.
\nA rule answers: what follows, and what reacts? It has two kinds, one for relations and one for constraints.
\nDerivation rules work over relations: they work out new facts from existing ones, until nothing new appears. This is Datalog, and it ships:
\nrelation Edge = {from: String, to: String}\n\nrelation Reachable(src: String, dst: String) :-\n Edge(from: src, to: dst)\n\nrelation Reachable(src: String, dst: String) :-\n Edge(from: src, to: mid), Reachable(src: mid, dst: dst)Rewrite rules work over constraints: they match several facts in a store at once, check a condition, and replace what they matched. This is CHR, Constraint Handling Rules, and it ships too. A rule matches facts with on, takes the ones it names out of the store with remove, and adds constraints and events with tell. The facts it does not remove stay in the store.
\nconstraint Bucket = {id: String, tokens: Int, max_tokens: Int}\nconstraint Request = {id: String}\nevent Allowed = {id: String, remaining: Int}\n\nrule consume_token =\n on Request(id: rid) as req, Bucket(id: rid, tokens: t, max_tokens: m) as bucket\n remove req, bucket\n when t > 0\n tell Bucket(id: rid, tokens: t - 1, max_tokens: m),\n Allowed(id: rid, remaining: t - 1)\n endMatching several facts at once is what a function can't do. You call a function with its input. A rule matches a combination of facts in the store (rid in both patterns is a join), and the engine decides when it fires.
\n\nA function runs when called. A rule runs when the world makes it true.
\n
Because a rule is a declaration and not control flow, the compiler can inspect it. Today it checks that every guard has no side effects and always gives the same answer. It also checks that a guard cannot go from true to false as more facts arrive, so the order of arrival cannot change the result. Checking that a rule set always terminates is on the roadmap.
\nRun the alarm once more, end to end. The temperature is a signal. When it crosses the threshold, the crossing is told to the store. A rewrite rule matches it, latches the alarm fluent, and emits an event so the rest of the system hears about it. When an acknowledgement arrives, another rule terminates the fluent. Four roles and two nouns, none standing in for another.
\nPut them side by side and the table is clean enough that I take it as evidence these are real, not invented:
\n| Noun or role | The question it answers | Its verbs | What it separates |\n|
\n", "date_modified": "2026-10-12T00:00:00.000Z", "author": { "name": "Alejandro M. Ramallo" }, "tags": [ "Language", "Shapes", "Data Modeling" ] }, { "id": "https://bondy.io/posts/2026-10-12-bondy-as-consilience", "content_html": "I'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative[1] language for the BEAM: statically typed, functional, relational and rule-based.
\nBondy is a brand about connecting everything to everything. Not only in the networking sense, but in a deeper one that has shaped how I've built software for as long as I've been building it. It is the conviction that many of the things we normally keep in separate boxes were always meant to belong together. Bondy is the name I gave to that conviction.
\nIt began as the name of our distributed application networking (DAN) platform. It removed the bureaucratic middleware the market kept throwing at us: the service mesh, the API gateway, the RPC framework, the pub/sub broker. Each solved a sliver of the same problem, and each demanded its own security, its own infrastructure, its own configuration, its own learning curve. Collapsing all of that into one coherent thing was the most pressing pain in front of us at Leapsight, so that is where I started. But the application networking platform was only ever one piece of Bondy.
\nThe ambition behind the brand was always larger: to take a great many beautiful and inspired ideas from computer science and bring them together into a single, coherent whole. The market neglected some of them for commercial rather than technical reasons. The application networking platform solved one piece of that puzzle. It was never the puzzle.
\n\n\nIf you do this work long enough, you stop collecting tools and start collecting convictions.
\n
Mine accumulated slowly, one project at a time. By the late nineties they lived in an Eastgate Tinderbox file — my intellectual drawers made digital — and it was filling up. OpenStep, distribution, tuplespaces, Lifestreams, Xanadu, JINI, Datalog, logic and constraint programming, Meta Content Framework and RDF, FIPA agents, Erlang. Notes linked to notes linked to notes, about systems that to everyone else lived in different fields and different conferences. But to me they kept pointing at the same underlying thing.
\nMost of those ideas were not mine. They belonged to researchers and communities far smarter than me. What was mine was a stubborn feeling that they belonged together. They were not a handful of separate problems with separate solutions, but facets of one problem the world had never let sit in the same room.
\nFor a long while they stayed in separate drawers, because the industry insisted they belonged there, or because the best technology does not always win.
\nI remember approaching one of the engineers behind the first version of OS X Spotlight, announced at Apple's WWDC in 2004. When I asked him why Spotlight wasn't built as an RDF store, he asked me what RDF was. This was shocking, given that RDF's ancestor—the Meta Content Framework (MCF)[2]—was actually created at Apple and showcased by HotSauce[3]. At least now, almost 20 years later, RDF has finally found its way back to Apple[4].
\n\nWhen we have unified enough certain knowledge, we will understand who we are and why we are here. If those committed to the quest fail, they will be forgiven. When lost, they will find another way. The moral imperative of humanism is the endeavour alone, whether successful or not, provided the effort is honorable and failure memorable.\n\n
I found the word for it in 1998, when I read Consilience: The Unity of Knowledge by E. O. Wilson. Wilson used it to mean the "jumping together" of knowledge — the way facts and theories from unrelated disciplines link up into a common groundwork of explanation. It is the opposite of specialisation: the belief that the seams between fields are artefacts of how we organised our universities, not features of reality.
\nThat named the drawer. What I'd been assembling wasn't a reading list or a wiki. It was a consilience waiting to happen.
\nAnd that is what Bondy has always been reaching for. Not a product with a long feature list, but a consilience. There, the ideas I'd been carrying for decades could finally stop being neighbours and start being one thing.
\n\n\nThe language is where the ambition was pointing the entire time.
\n
These ideas have to actually unify: not sit side by side, but compose, reinforce each other and become guarantees you can lean on. For that, they can't live in the plumbing. They have to live in the language you write your program in, and in the runtime that executes it.
\nI want to be careful here, because it would be easy to read this as one thing turning into another: the application networking platform growing up into a language. It isn't that. Both are expressions of the same philosophy, and they solve different amounts of the puzzle. I began with the networking platform because I wasn't ready to solve the whole thing yet, and because the middleware tax was the pain right in front of us. What the language actually is — and how it makes these ideas cohere — is what the rest of this series is for.
\nThere is a second reason, and it is newer than the drawer.
\nLanguage models now write a growing share of software. That changes the economics of code, and it raises the stakes. For the systems that matter, the risk is no longer that the code cannot be produced. It is that nobody can understand, review or maintain what was produced, as it grows faster than anyone reads it.
\nSome argue the opposite: once machines write the code, the language stops mattering. I think that gets it backwards. The less of the code a human writes, the more the language has to carry the meaning a human can check.
\nA declarative program says what must be true, not the sequence of steps that happens to make it true today. It is mostly facts, rules and constraints, with little control flow in between, and that is what both people and models get right most often. A model is far more likely to get a rule, relation, constraint or type right than a long chain of imperative updates. Those updates must stay in sync across a dozen code paths. And a reviewer is far more likely to spot the one that is wrong.
\nThis is not a hypothesis. At Leapsight we see a reduction of 10x to 15x in lines of code compared to the Erlang that does the same job. The difference is the declarative part. The shapes, rules, relations and constraints that Erlang makes you spell out as control flow are one-line statements in Bondy. Less code is less to write, and above all less to review.
\nThe payoff is the same for people and for machines. Invariants live in one place, so programs are cheaper to change. Anything that can be worked out from other facts is written once as a rule, not kept in sync by hand, so there are fewer places for bugs to hide. And the program reads like its specification, so reviewing it means reading what it claims. Add a compiler that knows what every function is allowed to do, and code written by a tool can run with only the permissions you grant it. The seventh post is about that.
\nThe BEAM already gives us the operational foundation for systems that keep running. Bondy adds the semantic one. That matters most now that we write those systems together with machines.
\nIn its application networking platform years, Bondy was the connective tissue made visible. WAMP gave anything a common protocol to talk to anything, and clustering and replication let the whole thing survive a machine dying. We arranged all of it so the accidental complexity fell away and only the essential part remained.
\nThat role isn't going away, but the name is now expanding to cover the entire ambition. Meanwhile, the application networking platform itself is getting its own distinct name: Bondy Connect. Far from being retired or diminished, it is finally graduating to v1.0.0. For the first time, it is being named precisely. It is the mesh—the fabric that allows everything to communicate. It has earned its name, and it continues to do its job.
And Bondy — just Bondy — is the brand and the philosophy, of which the language is the fullest expression. The attempt to take every idea I ever found beautiful in computer science and make them cohere into something you can actually program in. That includes the ones the market quietly left for dead.
\nThis isn't a rebrand in the marketing sense, where a logo changes and nothing else does. It's naming things correctly at last. The brand always meant more than an application networking platform. Giving it its own name lets Bondy finally stand for the whole of the ambition rather than one part of it.
\nConsilience is not something you announce and then possess. It's something you build toward, imperfectly, for a long time, and Bondy has a long way still to go. But for the first time the name and the ambition point at the same thing.
\n\n\nAfter decades of gluing, the seams are starting to disappear.\nBondy was a brand that wanted to be more than an application networking platform. It finally is.
\n
I wrote the rest of the series for people who will type this in, so here is one module before the argument. It is a rate limiter that knows which features each plan includes. Every line compiles on the current toolchain, and every line is explained later in the series.
\nmodule Limiter implements GenReactor(Event = Allowed | Denied)\n\nimport GenReactor.{type Reply, NoReply}\n\n%% -----------------------------------------------------\n%% Types\n%% What a valid value looks like.\n%% -----------------------------------------------------\ntype Config = {max_tokens: Int & > 0 & =< 10000}\n\n%% -----------------------------------------------------\n%% Relations\n%% Facts you look up, and rules that derive more \n%% of them.\n%% -----------------------------------------------------\n\nrelation Extends = {plan: String, parent: String}\nrelation Grants = {plan: String, feature: String}\n\nfact Extends(plan: \"pro\", parent: \"free\")\nfact Grants(plan: \"free\", feature: \"api\")\nfact Grants(plan: \"pro\", feature: \"webhooks\")\n\nrelation Has(plan: String, feature: String) :-\n Grants(plan: plan, feature: feature)\n\nrelation Has(plan: String, feature: String) :-\n Extends(plan: plan, parent: p), \n Has(plan: p, feature: feature)\n\n%% -----------------------------------------------------\n%% Constraints and Rules\n%% Facts you impose on a store, rules that react, \n%% events that leave.\n%% -----------------------------------------------------\n\nconstraint Bucket = {id: String, tokens: Int}\nconstraint Request = {id: String}\n\nevent Allowed = {id: String, remaining: Int}\nevent Denied = {id: String}\n\nrule consume_token =\n on \n Request(id: rid) as req, \n Bucket(id: rid, tokens: t) as bucket\n remove \n req, bucket\n when \n t > 0\n tell \n Bucket(id: rid, tokens: t - 1),\n Allowed(id: rid, remaining: t - 1)\n end\n\nrule deny =\n on \n Bucket(id: rid, tokens: 0), \n Request(id: rid) as req\n remove \n req\n tell \n Denied(id: rid)\n end\n\n%% -----------------------------------------------------\n%% Functions, with what they may do checked by the compiler.\n%% -----------------------------------------------------\n\n@law(:pure, :deterministic)\npublic function capacity(cfg: Config) :: Int -> \n cfg.max_tokens\n\npublic function features(plan: String) ->\n query Has(plan: plan, feature: f) end\n\npublic function init(_args) -> \n Ok([])\n\npublic function handle_event(Allowed() as e, _ctx) -> \n Reply(value: e)\npublic function handle_event(Denied() as e, _ctx) -> \n Reply(value: e)\npublic function handle_event(_, _) -> \n NoReply()Two nouns the BEAM already gives you, functions and processes. Three that Bondy adds: the shape, which describes which values are allowed (Config above is a named one), the rule, and the signal. Four roles a value can play: relation, constraint, event and fluent. Shapes, relations, constraints, events and both kinds of rule are in the compiler today, and so is the check on what every function is allowed to do. Fluents and signals are designed and next, and every post that touches them says so.
One post per idea, with code you can compile:
\nhandle_call.Declarative is a spectrum, not a label, and BEAM programmers will rightly say that Erlang, Elixir and Gleam are declarative already. They are, in one sense: you write expressions over immutable values, not statements that change memory. But you still write the algorithm (which map to look in, which branch to take) and you still thread the state from one call to the next. Bondy keeps that functional core and goes further along the same line. With relations, rules and constraints you state the facts and what must hold, and the engine decides the order, the lookups and where the state lives. The glossary entry has the longer version. ↩︎
\nThe Meta Content Framework (MCF) is an early metadata specification developed by Ramanathan V. Guha at Apple Computer between 1995 and 1997 to structure information and relationships on the web. ↩︎
\nHotSauce, code-named Project X, was an experimental 3D web browser and plug-in. Apple Computer developed it in 1996 as a sample application of its Meta Content Framework (MCF). ↩︎
\nSaga: A Platform for Continuous Construction and Serving of Knowledge At Scale ↩︎
\nI'm publishing this series ahead of Code BEAM Europe this October, where I'll reveal Bondy, a new declarative[^declarative] language for the BEAM: statically typed, functional, relational and rule-based.
\nBondy is a brand about connecting everything to everything. Not only in the networking sense, but in a deeper one that has shaped how I've built software for as long as I've been building it. It is the conviction that many of the things we normally keep in separate boxes were always meant to belong together. Bondy is the name I gave to that conviction.
\nIt began as the name of our distributed application networking (DAN) platform. It removed the bureaucratic middleware the market kept throwing at us: the service mesh, the API gateway, the RPC framework, the pub/sub broker. Each solved a sliver of the same problem, and each demanded its own security, its own infrastructure, its own configuration, its own learning curve. Collapsing all of that into one coherent thing was the most pressing pain in front of us at Leapsight, so that is where I started. But the application networking platform was only ever one piece of Bondy.
\nThe ambition behind the brand was always larger: to take a great many beautiful and inspired ideas from computer science and bring them together into a single, coherent whole. The market neglected some of them for commercial rather than technical reasons. The application networking platform solved one piece of that puzzle. It was never the puzzle.
\n\n\nIf you do this work long enough, you stop collecting tools and start collecting convictions.
\n
Mine accumulated slowly, one project at a time. By the late nineties they lived in an Eastgate Tinderbox file — my intellectual drawers made digital — and it was filling up. OpenStep, distribution, tuplespaces, Lifestreams, Xanadu, JINI, Datalog, logic and constraint programming, Meta Content Framework and RDF, FIPA agents, Erlang. Notes linked to notes linked to notes, about systems that to everyone else lived in different fields and different conferences. But to me they kept pointing at the same underlying thing.
\nMost of those ideas were not mine. They belonged to researchers and communities far smarter than me. What was mine was a stubborn feeling that they belonged together. They were not a handful of separate problems with separate solutions, but facets of one problem the world had never let sit in the same room.
\nFor a long while they stayed in separate drawers, because the industry insisted they belonged there, or because the best technology does not always win.
\nI remember approaching one of the engineers behind the first version of OS X Spotlight, announced at Apple's WWDC in 2004. When I asked him why Spotlight wasn't built as an RDF store, he asked me what RDF was. This was shocking, given that RDF's ancestor—the Meta Content Framework (MCF)[^MCF]—was actually created at Apple and showcased by HotSauce[^Hotsauce]. At least now, almost 20 years later, RDF has finally found its way back to Apple[^SAGA].
\n\nWhen we have unified enough certain knowledge, we will understand who we are and why we are here. If those committed to the quest fail, they will be forgiven. When lost, they will find another way. The moral imperative of humanism is the endeavour alone, whether successful or not, provided the effort is honorable and failure memorable.\n\n
I found the word for it in 1998, when I read Consilience: The Unity of Knowledge by E. O. Wilson. Wilson used it to mean the "jumping together" of knowledge — the way facts and theories from unrelated disciplines link up into a common groundwork of explanation. It is the opposite of specialisation: the belief that the seams between fields are artefacts of how we organised our universities, not features of reality.
\nThat named the drawer. What I'd been assembling wasn't a reading list or a wiki. It was a consilience waiting to happen.
\nAnd that is what Bondy has always been reaching for. Not a product with a long feature list, but a consilience. There, the ideas I'd been carrying for decades could finally stop being neighbours and start being one thing.
\n\n\nThe language is where the ambition was pointing the entire time.
\n
These ideas have to actually unify: not sit side by side, but compose, reinforce each other and become guarantees you can lean on. For that, they can't live in the plumbing. They have to live in the language you write your program in, and in the runtime that executes it.
\nI want to be careful here, because it would be easy to read this as one thing turning into another: the application networking platform growing up into a language. It isn't that. Both are expressions of the same philosophy, and they solve different amounts of the puzzle. I began with the networking platform because I wasn't ready to solve the whole thing yet, and because the middleware tax was the pain right in front of us. What the language actually is — and how it makes these ideas cohere — is what the rest of this series is for.
\nThere is a second reason, and it is newer than the drawer.
\nLanguage models now write a growing share of software. That changes the economics of code, and it raises the stakes. For the systems that matter, the risk is no longer that the code cannot be produced. It is that nobody can understand, review or maintain what was produced, as it grows faster than anyone reads it.
\nSome argue the opposite: once machines write the code, the language stops mattering. I think that gets it backwards. The less of the code a human writes, the more the language has to carry the meaning a human can check.
\nA declarative program says what must be true, not the sequence of steps that happens to make it true today. It is mostly facts, rules and constraints, with little control flow in between, and that is what both people and models get right most often. A model is far more likely to get a rule, relation, constraint or type right than a long chain of imperative updates. Those updates must stay in sync across a dozen code paths. And a reviewer is far more likely to spot the one that is wrong.
\nThis is not a hypothesis. At Leapsight we see a reduction of 10x to 15x in lines of code compared to the Erlang that does the same job. The difference is the declarative part. The shapes, rules, relations and constraints that Erlang makes you spell out as control flow are one-line statements in Bondy. Less code is less to write, and above all less to review.
\nThe payoff is the same for people and for machines. Invariants live in one place, so programs are cheaper to change. Anything that can be worked out from other facts is written once as a rule, not kept in sync by hand, so there are fewer places for bugs to hide. And the program reads like its specification, so reviewing it means reading what it claims. Add a compiler that knows what every function is allowed to do, and code written by a tool can run with only the permissions you grant it. The seventh post is about that.
\nThe BEAM already gives us the operational foundation for systems that keep running. Bondy adds the semantic one. That matters most now that we write those systems together with machines.
\nIn its application networking platform years, Bondy was the connective tissue made visible. WAMP gave anything a common protocol to talk to anything, and clustering and replication let the whole thing survive a machine dying. We arranged all of it so the accidental complexity fell away and only the essential part remained.
\nThat role isn't going away, but the name is now expanding to cover the entire ambition. Meanwhile, the application networking platform itself is getting its own distinct name: Bondy Connect. Far from being retired or diminished, it is finally graduating to v1.0.0. For the first time, it is being named precisely. It is the mesh—the fabric that allows everything to communicate. It has earned its name, and it continues to do its job.
And Bondy — just Bondy — is the brand and the philosophy, of which the language is the fullest expression. The attempt to take every idea I ever found beautiful in computer science and make them cohere into something you can actually program in. That includes the ones the market quietly left for dead.
\nThis isn't a rebrand in the marketing sense, where a logo changes and nothing else does. It's naming things correctly at last. The brand always meant more than an application networking platform. Giving it its own name lets Bondy finally stand for the whole of the ambition rather than one part of it.
\nConsilience is not something you announce and then possess. It's something you build toward, imperfectly, for a long time, and Bondy has a long way still to go. But for the first time the name and the ambition point at the same thing.
\n\n\nAfter decades of gluing, the seams are starting to disappear.\nBondy was a brand that wanted to be more than an application networking platform. It finally is.
\n
I wrote the rest of the series for people who will type this in, so here is one module before the argument. It is a rate limiter that knows which features each plan includes. Every line compiles on the current toolchain, and every line is explained later in the series.
\nmodule Limiter implements GenReactor(Event = Allowed | Denied)\n\nimport GenReactor.{type Reply, NoReply}\n\n%%