Skip to content

CONCEPT Cited by 1 source

Purely functional policy language

Definition

A purely functional policy language is a policy-authoring language where:

  1. Policies are pure functions — no side effects, no shared mutable state — so two policies cannot interact in ways the author did not intend.
  2. Policies are strongly typed — type errors are compile-time errors, catching classes of bug (null references, shape mismatches, protocol drift) before production.
  3. The language has the abstraction facilities needed to express real-world policy complexity (user-defined types, modules, higher-order functions, pattern matching).

This is a language-level property set rather than a single feature — it shows up in the wiki as the root rationale Meta gave for choosing Haskell as the policy-authoring language for Sigma (sources/2015-06-26-meta-fighting-spam-with-haskell).

Meta's articulation

From the Sigma rewrite post:

  1. Purely functional and strongly typed. This ensures that policies can't inadvertently interact with each other, they can't crash Sigma, and they are easy to test in isolation. Strong types help eliminate many bugs before putting policies into production.

Three production-safety properties derived directly from the language properties:

  • Policies can't interact. A purely functional policy has no shared mutable state with any other policy. The engine can run many policies in one process, with one interpreter / runtime, and not worry that policy A will corrupt state policy B depends on. This is load-bearing at Sigma scale because all policies run together; the engine trusts the language's isolation guarantees rather than enforcing isolation at a process boundary.
  • Policies can't crash the engine. Strong typing plus pure functions plus GHC's runtime's allocation limits and asynchronous exceptions mean a broken policy terminates itself — it cannot bring the engine down.
  • Easy to test in isolation. A pure function's output depends only on its inputs. Unit tests are trivial; mocking external services is a matter of providing a fake data source.

Operational coupling: type-correct-or-rejected at repo ingress

The language property is paired with a policy:

We don't allow code to be checked into the repository unless it is type-correct.

This is the repo-level gate that makes the continuous policy deploy posture viable. If any type-incorrect policy could land in the repo, the "source code in the repository is the code running in Sigma" posture would require reverting + redeploying; the gate ensures the repo is always deployable.

Why this matters architecturally

This concept names the language-as-production-safety-primitive stance. Many rule engines (think: firewall configs, SQL WHERE clauses, Rego, OPA) use dedicated DSLs specifically to get a guaranteed set of safety properties. Sigma chose a general-purpose language whose type system and purity already provide those properties — avoiding the expressivity ceiling an in-house DSL eventually hits (see FXL).

The canonical wiki takeaway: if your rule engine's authors need user-defined data types, modules, higher-order functions, and performance competitive with C++, but you also need policy isolation and engine-crash protection, a purely functional strongly-typed general-purpose language can be a credible choice over a specialised DSL — if you accept the cost of the runtime (GHC, managed heap, GC) and if you have people who can contribute to the compiler when you need it.

When this applies

  • Rule engines, policy engines, anti-abuse systems, fraud-detection systems, feature-flag evaluators where many independent rules must co-exist in one process.
  • Systems where continuous deployment of rules by non-infra engineers is required and the only safety net is what the language gives you.

When it doesn't

  • Rules that must mutate shared state (counters, rate limiters, circuit breakers) — these are typically pushed to a library layer the pure policies call, not embedded in the policies themselves.
  • Simple rule sets where a tiny embedded DSL (a JSON shape, a Boolean expression mini-language) is sufficient and a full compiled language is overkill.

Seen in

Last updated · 319 distilled / 1,201 read