Portable computation and active data
Part of the sUTL history essay, with current release notes distinguishing shipped behavior from future ideas.
sUTL · Guide · Reference · Examples
This essay records the history and design direction of sUTL. Since the original reconstruction, sUTL 1.0 and JavaScript, Python and Go packages have been released. Implementation releases from 1.1.0 support step/depth limits and cancellation. Compiler and native-code-generation ideas below remain proposals. See the current reference and sUTL in Everything.
Why the idea still seems useful
When I originally described sUTL as a transformation language, the obvious comparison was to templating and JSON manipulation tools.
Today I would describe its strongest use case somewhat differently.
sUTL is potentially a portable, deterministic, capability-safe computation language for structured values.
That is useful anywhere a system would like to accept computation from another party without accepting arbitrary executable code.
Consider an API returning large records.
A conventional endpoint may support projection:
GET /customers?fields=id,name,email
But projection only selects fields.
Instead, the endpoint could accept an sUTL transform and apply it to each record before returning anything.
The caller could reshape nested structures, calculate values, normalize data, extract selected descendants or construct an entirely different result.
The computation occurs near the data, so the service need not transmit a huge record when the caller only needs a small derived value.
Yet the caller has not been allowed to upload arbitrary JavaScript or Python.
The transform can only compute from values it has been given.
This is safe computation pushdown.
It is particularly attractive for agents. An agent receiving a 200 KB API response may only need a 2 KB derived structure. Rather than transferring everything and spending model tokens interpreting it, the agent could construct a small transform and ask the service to execute it locally.
The same idea applies to stored transformations.
A pipeline service might allow a caller to upload and persist a transform:
incoming record
↓
stored transform A
↓
stored transform B
↓
destination
The stored stages are executable, but they are not arbitrary foreign code.
Because they are pure transformations over MLSNBN, the runtime does not need to give them filesystem access, sockets, environment variables, process creation, credentials or reflection.
They can be versioned as data, replayed against historical inputs and moved between compatible runtimes.
That is a much smaller security problem than hosting general-purpose scripts.
Active data
There is a related idea that I find even more interesting now.
Instead of storing only a value, a system can store a transform that evaluates to that value.
Literal data is then simply the trivial case of a transform.
More interesting stored values can contain derived structure:
plain data
↓
data with calculated pieces
↓
parameterised document
↓
transformation template
↓
full computation
A configuration document could be a transform that evaluates against an environment to produce concrete configuration.
A stored customer "view" could be a transform evaluated against raw customer data.
An API representation could be stored as a transformation rather than as duplicated materialized data.
An invoice definition could be a transform that produces an invoice value from its context.
Because the program is itself MLSNBN, all of these definitions remain ordinary structured values at rest.
This is something Lisp made conceptually natural, but MLSNBN makes unusually interoperable.
Purity should remain non-negotiable
One temptation would be to make sUTL more useful by adding impure builtins:
http_get
read_file
database_query
now
random
I think that would destroy one of its best properties.
The useful invariant is:
A sUTL transform cannot do anything except compute a value from values it has been given.
That does not mean a larger system built around sUTL cannot perform effects.
The right model is much closer to a modern LLM tool harness.
If a program needs an HTTP operation, the transform can emit an MLSNBN value describing the requested operation:
{
"$effect": "http",
"args": {
"method": "GET",
"url": "https://example.com/customer/123"
}
}
The sUTL evaluator has still done nothing impure.
An external harness can inspect that value, decide whether the operation is allowed, apply authentication and policy, execute it, and pass the MLSNBN result into the next transform.
The execution model becomes:
input
↓
pure sUTL
↓
effect description
↓
external harness
↓
effect result
↓
pure sUTL
This cleanly separates describing an effect from having authority to perform one.
The same transform can therefore run under a test harness, a browser harness, a locked-down server harness or an agent harness with different effect policies.
Effects remain inspectable, auditable and replayable.
sUTL stays pure.
Turing completeness and resource safety
Purity gives strong capability safety, but it does not by itself solve resource safety.
A Turing-complete transform can still loop forever, recurse excessively, traverse large structures repeatedly or construct enormous intermediate results.
A modern runtime should therefore be metered.
The natural model is fuel or another deterministic execution budget.
For example, an execution environment might enforce limits on:
evaluation steps
recursion depth
intermediate allocation
output size
wall-clock time
Every operation consumes some amount of budget. When the budget is exhausted, evaluation terminates with a resource-limit result.
This is a much simpler security boundary than trying to sandbox arbitrary JavaScript.
It also preserves the lesson learned from bOTL.
The answer to computational complexity was not to cripple the language until difficult transformations became impossible. It was to make the language expressive, then control the execution environment explicitly.
Read the essay
From bOTL to sUTL · Portable computation and active data · Compilation and the future of sUTL
Source
Adapted from the sUTL source material.