Coder Legion - Recent posts tagged scrml

While my keyboard gently weeps.

Sat, 31 Oct 2026 16:11:22 +0000

So a job offer came in. The company offering it is one I helped build. In fact, the "I just don't give a what" profile picture that I use here was taken by the same guy offering me the position.

The "basin boys" came into the cementing game taking no prisoners and offering no quarter. We perfected the 2-stage 1-shot technique That is now used by every cementing company around. We made the name synonymous with quality work. Now they want me back, to put much of my oil-field and down-hole specific knowledge to work again.

I don't need the job. I can always fall back to truck driving; I own the equipment, so it's not like I would have to interview. So this isn't about money. It's a real choice.

And the real question before me is: do I pause the work on scrml?

If I take this job, it will consume my time my mind and my efforts. I know that going in. because it is who I am. And what the job requires.

While running my own company has allowed me time to focus on building scrml.

Building a language that doesn't exist yet, and writing programs in it, is a special kind of thing.

That's what excites me. But special for whom? The level of interest in this project appears to be approaching absolute zero.

There is an aire of finality here that scares the hell out of me.

and a silence that should cry havoc

I have to wonder: is that my answer?

Or just the voice of frustration, screaming, to unleash the dogs of war?

Do I go quietly into the night?

Or is it time to actually get loud?

And if it is the latter, well; Y`all aint seen nothing yet.

Go type yourself!

Fri, 30 Oct 2026 17:47:29 +0000

DHH said that typescript is pure "type masterbation". And though I agree with his premise, It is a fixable problem. And I say we use the type system to do just that.

There is a familiar complaint about TypeScript: too much of the code is types talking to other types. Generic wrappers, schemas restating the same shapes, never tricks to force a switch to be complete. Very little of it does anything at run time.

The complaint is fair, but it usually lands on the wrong target. The TypeScript in a typical full-stack feature is not careless. It is what you have to write to get the guarantees, because TypeScript can't see the parts that matter: what crosses the network, which errors can happen, and whether you handled all of them.

Here is a small, ordinary feature. A page loads a post's title and shows a different message for each way loading can fail.

In TypeScript

// shared/types.ts — the wire contract, stated as types AND as a runtime schema
import { z } from "zod";

export const PostRow = z.object({ title: z.string(), owner: z.string() });
export type PostRow = z.infer<typeof PostRow>;

export type LoadError =
  | { kind: "NotFound"; id: string }
  | { kind: "Forbidden" }
  | { kind: "Unavailable" };

export type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };
export type ApiResponse = Result<string, LoadError>;

// the same contract again, so the client can check at runtime what TS only assumes
export const ApiResponseSchema = z.discriminatedUnion("ok", [
  z.object({ ok: z.literal(true), value: z.string() }),
  z.object({ ok: z.literal(false), error: z.discriminatedUnion("kind", [
    z.object({ kind: z.literal("NotFound"), id: z.string() }),
    z.object({ kind: z.literal("Forbidden") }),
    z.object({ kind: z.literal("Unavailable") }),
  ]) }),
]);

export function assertNever(x: never): never {
  throw new Error(`Unhandled: ${JSON.stringify(x)}`);
}

// app/api/post/route.ts
export async function GET(req: Request): Promise<Response> {
  const id = new URL(req.url).searchParams.get("id") ?? "";
  const viewer = await getViewer(req);
  let row: PostRow | undefined;
  try {
    row = PostRow.optional().parse(
      db.prepare("SELECT title, owner FROM posts WHERE id = ?").get(id));
  } catch {
    return Response.json({ ok: false, error: { kind: "Unavailable" } } satisfies ApiResponse);
  }
  if (!row) return Response.json({ ok: false, error: { kind: "NotFound", id } } satisfies ApiResponse);
  if (row.owner !== viewer) return Response.json({ ok: false, error: { kind: "Forbidden" } } satisfies ApiResponse);
  return Response.json({ ok: true, value: row.title } satisfies ApiResponse);
}

// client
type ClientError = LoadError | { kind: "Transport" };

async function loadTitle(id: string): Promise<Result<string, ClientError>> {
  let res: Response;
  try { res = await fetch(`/api/post?id=${encodeURIComponent(id)}`); }
  catch { return { ok: false, error: { kind: "Transport" } }; }
  const parsed = ApiResponseSchema.safeParse(await res.json());
  return parsed.success ? parsed.data : { ok: false, error: { kind: "Transport" } };
}

function label(r: Awaited<ReturnType<typeof loadTitle>>): string {
  if (r.ok) return r.value;
  switch (r.error.kind) {
    case "NotFound":    return `No post ${r.error.id}`;
    case "Forbidden":   return "Not yours";
    case "Unavailable": return "Try again later";
    case "Transport":   return "Network trouble";
    default:            return assertNever(r.error);
  }
}

In scrml

<program db="./app.db">

type LoadError:enum = { NotFound(id: string), Forbidden, Unavailable }

function loadTitle(id: string, viewer: string) ! LoadError {
    let row = ?{`SELECT title, owner FROM posts WHERE id = ${id}`}.get() !{
        _ :> { fail .Unavailable }
    }
    if (row is not) { fail .NotFound(id) }
    if (row.owner != viewer) { fail .Forbidden }
    return row.title
}

<msg> = ""

function show(id: string) {
    @msg = loadTitle(id, "me") !{
        .NotFound(mid) :> "No post " + mid
        .Forbidden     :> "Not yours"
        .Unavailable   :> "Try again later"
        .Transport(_)  :> "Network trouble"
    }
}

<button onclick=show("1")>Load</>
<p>${@msg}</p>

</program>

Now is'nt that just so much nicer to read?

Where the TypeScript went

TypeScript	scrml
`LoadError` as a union of objects tagged with `kind`	`type LoadError:enum`: variants with payloads are part of the language
`Result<T, E>`, and `ok: true/false` wrapping at every return	`! LoadError` on the signature, `fail .X` in the body. A function that can fail is a language feature, not a library type
A Zod schema restating the wire type so the client can check it at run time	Nothing. `loadTitle` runs on the server because it touches the database, and the compiler writes the encoding for its result and its errors
An API route, a URL, `fetch`, a `try` around `fetch`, and a hand-made `"Transport"` error	`loadTitle(id, "me")` is an ordinary call. A network failure arrives as the built-in `.Transport` variant
`assertNever` and a `default:` branch to make the `switch` complete	The compiler refuses an incomplete handler. Delete the `.Forbidden` line and the build fails: `E-TYPE-080: Non-exhaustive error handler for LoadError. Missing variant(s): Forbidden`
`satisfies ApiResponse` on every `Response.json`	Nothing to satisfy, because no response is written by hand
`Awaited<ReturnType<typeof loadTitle>>`	Nothing to derive, because no type is threaded through generics

The point

None of the TypeScript above is bad. Every line restates something TypeScript cannot see on its own:

the shape of what crosses the wire;
the set of errors a call can produce;
whether every one of them was handled.

You write those types because the compiler is blind to the server, the network and the client as one program.

scrml's compiler is not blind to them. It compiles the server function, the encoding between server and browser, and the client in one pass. So it already knows the error set, already writes the encoding, and can check exhaustiveness itself. You don't need fewer guarantees. You just don't have to restate them by hand.

Markdown without a back door:

Tue, 27 Oct 2026 18:54:33 +0000

How scrml lets an author write bold instead of , and why nothing inside an block can ever run.

Where this came from
It started with a security review, not a feature request. scrml treats the bodies of

 and  as raw content, and until this week the compiler copied raw content into the page exactly as written. A review then ran these through a real Chromium:

// the handler runs

// a same-origin script runs

// the CSS applies

The fix was a ruling: raw bodies now render as text. < and > are encoded, & is left alone so the many existing <…> code samples keep working, and the common

…

wrapper stays a real element. Across 4,523 raw bodies in 12 repositories, that breaks nothing.

It also closed the last place an author could type formatting tags inside text. so I asked the obvious question: can scrml have a first-class , so an author gets the effect of bold without writing ?

The answer is yes. It took four decisions.

What it looks like
You write

<md>
    ## Filing a good bug report

    Before you file, **search the board**.

    - Say what you *expected*.
    - Paste the exact error in `backticks`.
    - Read the [triage guide](/docs/triage).
</md>

The page gets

…

Before you file,
search the board.

Say what you expected.
… backticks.
… …

The body is dedented the way Java text blocks are: the smallest indentation among the lines, counting the closing tag's line, is stripped. So sits naturally inside indented scrml markup. Static is turned into elements at build time and costs nothing at runtime.

DECISION 1 of 4

A value inside is text, never markdown
Ruled: ${…} inside is text-only.

## Welcome back, ${@user.name} Your last order shipped **${@order.date}**.

Now suppose a user sets their name to this:

Your account is locked

Verify here
If interpolated values were parsed as markdown, that name would render a fake heading and a phishing link. The link is a perfectly valid https URL, so no URL check would stop it. Under the rule we chose, the value goes in as plain text and can never create structure. The page shows the odd name literally.

This is the same contract scrml already uses for SQL. In ?{ … WHERE id = ${id} } the value is a bound parameter: data is never code. applies that rule to prose.

DECISION 2 of 4

Markdown from data gets its own, explicit form
Ruled: is part of , designed now and built second.

Comments, posts and CMS rows hold markdown that arrives at runtime. That is the dangerous case, so it does not happen by accident. It has its own spelling:

= ?{ SELECT body FROM posts WHERE id = ${id} }.get()

It uses the same reader and the same small set of output elements as static . A user's markdown can produce bold and a link, but never a script, an event handler or a javascript: link. Data-driven headings get no generated id, because ids chosen by users can overwrite DOM globals. The parser for this form ships only on pages that use of=; it is estimated at 3–6 KB gzipped, an estimate that has not been measured yet.

DECISION 3 of 4

A small dialect, one way to write each thing
bryan: "one way to do it with lints to guide"

In
paragraphs

headings

em and strong
inline code and fenced code
inline links and images
lists and > quotes
--- rules
tables and ~~strike~~
Out
raw HTML (shown as text)
indented code blocks
underlined === headings
reference-style links
entity references
https://… autolinks
footnotes and task lists
Markdown has several ways to write most things. scrml keeps one. When pasted markdown uses a dropped construct, a W-MD-* warning names the form to use instead, so a cut teaches rather than surprises.

Some cuts are forced. Indented code blocks had to go: lives inside indented source, and an indentation-sensitive construct would misfire constantly. MDX dropped them for the same reason. Others make the dialect safer. Raw HTML is the obvious one, and task lists are out because they would put form controls into the output. Djot, John MacFarlane's cleanup of CommonMark, made the same kinds of cuts.

DECISION 4 of 4

One markdown reader, written in scrml
Ruled: the parser is a single scrml module, scrml:md, used by both compilers.

scrml currently has two compilers: impl#1, written in TypeScript, and the self-hosting bootstrap, written in scrml. The markdown parser is written once, as an ordinary scrml module. impl#1 compiles it like any other stdlib module and uses it twice: at build time to turn static into elements, and as the runtime parser shipped for . The bootstrap uses the same module.

The alternatives were a TypeScript parser now and a scrml one later, or waiting for the bootstrap. The first means two readers of the same text, and two readers that can disagree is exactly the shape that kept producing security bypasses this session. The second means waiting. One reader avoids both. The cost is new machinery: impl#1 needs a hook that runs a scrml module at compile time. That hook gets the same adversarial review as everything else.

Why nothing inside can run
Most markdown renderers produce an HTML string and then clean it, by stripping , blocking javascript:, and so on. Those are lists of known-bad things, and the list is always one entry short. DOMPurify has a long run of mutation-XSS bypasses because what it checks and what the browser re-parses can differ. @nuxtjs/mdc had a CVE (CVE-2025-24981) for javascript: URLs hidden behind hex entities.

works the other way around. The renderer can only build a fixed set of elements, each with a fixed set of attributes: ElementAttributesWhere the value comes from p em strong del blockquote ul li hr br table thead tbody tr prenone— olstartdigits from the list marker th tdstyleone of three compiler constants for alignment h1–h6ida compiler slug, static only codeclasslanguage- plus letters, digits, _+- ahref, titlehref must pass scrml's URL allow-list imgsrc, alt, titlesrc must pass the same allow-list Content reaches the page only as text nodes or as values of those attributes. No HTML string is ever handed to the browser to parse. The URL check is scrml's existing allow-list, which admits http:, https:, mailto: and similar schemes rather than trying to name every dangerous one. A dangerous element the browsers add next year cannot appear, because has no way to build it. Who pays Authors can't put a

or inside . They close the block and write the element in ordinary scrml markup. People pasting from GitHub see raw HTML tags as text, and get a warning for each dropped construct. Pages that render user markdown ship the parser, estimated at 3–6 KB gzipped. Pages with only static ship nothing. The compiler gains a compile-time hook into a scrml module, which is new machinery to get right. Not covered: a comment rendered through of= can still say "click here to re-verify" with a real https link. That is content moderation, and true of every forum. Images in user markdown can also act as tracking pixels; an opt-in image policy is still an open question. Prior art The closest designs are Markdoc, from Stripe, which keeps content declarative and won't mix arbitrary code into it, and elm-markdown, which renders to a typed tree instead of an HTML string and fails loudly on unexpected HTML. Djot shaped the dialect cuts. Most static-site tools, such as Hugo and markdown-it, default to dropping raw HTML. Tools that pass it through, such as marked, leave sanitizing to the user; marked's README says so directly. Status: the four decisions were ruled in S462. The full design, including the prior-art table and the security model, is in scrml-support/docs/deep-dives/md-element-2026-10-11.md. Build phases: 1 is the SPEC section and the scrml:md parser (in progress); 2 is the impl#1 hook for static ; 3 is . This draft should be re-checked against the compiler once phase 2 lands, and every code block compiled before publishing.

Is there any way to make type conversion sexy? Nope

Tue, 20 Oct 2026 19:04:00 +0000

When converting a value of one type to another; There are conversions which never fail (ie int -> string). Some that can fail like string -> int, and then some lossy and implicit ones ( number -> int, int -> number)

How do we spell it in any of those situations?

My lean is to have a single tool with sane defaults. if you don't cover the error arm it wont compile and tell you why. That would look something like this:

<p>typed ${num} chars</> // No explicit cast needed, behaviour is dictated by the <p> parent

 <age:int | not=(int.parse(@txt))/> // "42" → 42, "abc" → not

type Guess:enum = { Yes, No }

<g:Guess | not=(Guess.parse(@txt))/>     // "Yes" → .Yes, "yes" → not

<p>${match @g {
    .Yes :> "yeppers",
    .No :> "nope",
    not :> "not a guess",
}}</p>

function qty(s: string) -> int {
    const n = int.parse(s)
    if (n is not) {
        return 0
    }
    return n                  // narrowed to int here
}

Lossy conversions are named, and round needs a tie mode

const avg = number.parse(@txt)          // number | not
// once narrowed:
floor(avg)                 // 3.7 → 3
ceil(avg)                  // 3.2 → 4
trunc(avg)                 // -3.7 → -3
round(avg, .HalfUp)        // 2.5 → 3
round(avg, .HalfEven)      // 2.5 → 2
round(avg)                 // error: name a tie mode

Into text: no conversion spelled, except where it's refused

<p>typed ${@txt.length} chars</p>          // ok: markup converts primitives
const msg = `typed ${@txt.length} chars`   // ok: a template is a text context
"typed " + @txt.length                     // error: + stays strict
label(@count)                              // error: int is not string
label(`${@count}`)                         // ok
<p>${@user}</p>                            // error: a struct has no one honest text form
fixed(@price, 2)                           // "3.14", from scrml:format

A bound number cell turns bad input into not

let <qty:int | not=0/>
<input type="text" bind:value=@qty/>      // "abc" writes not, never 0 or NaN


int.parse("42")       // 42
int.parse("-7")       // -7
int.parse(" 42")      // not   (no trimming)
int.parse("+42")      // not   (no plus sign)
int.parse("12px")     // not   (whole string or nothing)
int.parse("0x1F")     // not   (use scrml:math.parseInt(s, 16) for a radix)
int.parse("3.5")      // not   (tnumber, not an int)

number.parse("3.5")   // 3.5
number.parse("1e3")   // 1000
number.parse(".5")    // decided in the SPEC text; strict leans not

bool.parse("true")    // true
bool.parse("True")    // not
bool.parse("yes")     // not

Would anyone like to offer any criticism to this approach. Maybe a better idea.

I hope so

Function coloring the right way

Wed, 14 Oct 2026 16:25:46 +0000

Let It Leak Purity

Stop hating on functions. They can't help what color they are; they were born that way. You ought to know. You made them.

We all hate leaky abstractions. But if an abstraction is going to leak, I say let it leak purity.

That's not what async/await leaks. It's not what try/catch leaks. Those aren't abstractions, they're infections. Mark one function async and every caller has to turn async too. Throw from one place and every layer above it has to wrap itself in try. They spread through your code whether you want them or not, and what spreads carries no information: "something down there is slow," "something down there might blow up." Try/catch is the poisoned tree, and async/await is its deadly fruit. Neither deserves to see the light of day in a reasonable language.

Errors are enum variants. A function that can fail says so in its signature, and the caller handles every way it can fail, by name, or it doesn't compile.

Asynchronous code doesn't exist. Let that sit for a moment. Async is in your mind. There's no such thing as asking for data that doesn't exist yet. You ask for data, you get data. Never mind when; you get it before you need it, and the compiler handles the waiting.

No try. Only do.

That's the theory. Here's what it does to real code.

The code you actually write first

Nobody starts with a clean architecture. You start with the thing that works:

function checkout(lines: Line[]) {
  if (lines.length == 0) {
    @msg = "cart is empty"
    return
  }
  let t = 0
  for (const l of lines) { t = t + l.qty * l.cents }
  t = t + Math.round(t * 0.08)
  if (t > 100000) {
    @msg = "over limit: " + t
    return
  }
  ?{`INSERT INTO orders (cents, at) VALUES (${t}, ${now()})`}.run()
  @msg = "charged " + t
}

<button onclick=checkout(@cart)>Buy</button>
<p>${@msg}</p>

That compiles. It runs. scrml doesn't punish you for prototyping, and it shouldn't.

But look at what's knotted together in there. The arithmetic (line totals, tax). The business rules (an empty cart, a spending limit). The effects (a database write, a clock read). And the UI, because the only way this function can tell anyone it failed is by writing a sentence into a display cell. Nothing that calls checkout can know it failed. The failure is a string on a screen.

In most languages, that's where the code stays, because nothing pushes back.

Give the failure a name

Say the cart rules matter, and you'd like the caller to actually know when checkout didn't happen. So you give the failures names:

type CartError:enum = { Empty, OverLimit(cents: int) }

function checkout(lines: Line[])! -> CartError {
  if (lines.length == 0) { fail CartError::Empty }
  let t = 0
  for (const l of lines) { t = t + l.qty * l.cents }
  t = t + Math.round(t * 0.08)
  if (t > 100000) { fail CartError::OverLimit(t) }
  ?{`INSERT INTO orders (cents, at) VALUES (${t}, ${now()})`}.run()
  return t
}

function buy() {
  checkout(@cart)
}

The @msg writes are gone from checkout. It doesn't know there's a screen anymore; it says what happened and returns. And the very next thing the compiler does is refuse buy:

error [E-ERROR-002]: Result of failable function 'checkout' is not handled.
Either match the result, propagate with '?', catch with '!{}', or wrap in '<errorBoundary>'.

So the caller handles it, by name:

function buy() {
  const t = checkout(@cart) !{
    .Empty :> { @msg = "cart is empty"; return }
  }
  @msg = "charged " + t
}

Not good enough either:

error [E-TYPE-080]: Non-exhaustive error handler for `CartError`. Missing variant(s): OverLimit.

Every way it can fail, by name, or it doesn't compile. And notice where the UI text ended up: in buy, the function that owns the screen, not in checkout, the function that owns the order. You didn't decide to separate those. The error system moved them for you.

That's the first leak. It isn't an infection. It stops wherever you handle it, and you choose where that is.

Give the arithmetic a name

Now the math. You want to know that the total is right: same cart, same number, every time. So you try to say so:

fn total(lines: Line[]) -> int { ... }

fn is the pure color: same input, same answer, touches nothing. And here's the part that matters: once a function is pure, everything it calls has to be pure too, and the compiler holds that line. Leave any of the prototype's habits inside it and it's refused:

Inside an `fn`	Compiler says
`return now()`	E-FN-004: `now()` is non-deterministic; it reads host state
`return checkout(lines)`	E-FN-003: `checkout` is a `function`, not an `fn`
`?{ SELECT … }`	E-FN-001: a pure function may not touch the database
`@cart = []`	E-FN-003: a pure function may not write state

The only way to make total pure is to pull out everything that isn't. The clock goes. The database goes. The state writes go. What's left is arithmetic, and the arithmetic splits along the same line, because total can only call other fns:

fn lineTotal(l: Line) -> int { return l.qty * l.cents }
fn subtotal(lines: Line[]) -> int { return lines.reduce((a, l) => a + lineTotal(l), 0) }
fn tax(cents: int) -> int { return round(cents * 0.08) }
fn total(lines: Line[]) -> int { return subtotal(lines) + tax(subtotal(lines)) }

That's the second leak, and it flows the right way: down. The purity of total forced the purity of everything under it.

What leaked

Put it back together:

type CartError:enum = { Empty, OverLimit(cents: int) }

// pure: same input, same answer, touches nothing
fn lineTotal(l: Line) -> int { return l.qty * l.cents }
fn subtotal(lines: Line[]) -> int { return lines.reduce((a, l) => a + lineTotal(l), 0) }
fn tax(cents: int) -> int { return round(cents * 0.08) }
fn total(lines: Line[]) -> int { return subtotal(lines) + tax(subtotal(lines)) }

// impure: writes the database, reads the clock, can fail, and says how
function checkout(lines: Line[])! -> CartError {
  if (lines.length == 0) { fail CartError::Empty }
  const t = total(lines)
  if (t > 100000) { fail CartError::OverLimit(t) }
  ?{`INSERT INTO orders (cents, at) VALUES (${t}, ${now()})`}.run()
  return t
}

// owns the screen: handles every failure by name
function buy() {
  const t = checkout(@cart) !{
    .Empty        :> { @msg = "cart is empty"; return }
    .OverLimit(c) :> { @msg = "over limit: " + c; return }
  }
  @msg = "charged " + t
}

Same behavior as the prototype. But now the signatures tell you the truth about the program. Which parts are calculation (fn). Which parts touch the world (function). What can go wrong, and every way it can (! -> CartError). Who owns the screen (whoever handles the variants). And there's still no async, no await, no try anywhere: checkout hits the database, buy calls it like any other function, and the compiler writes the waiting itself.

None of that structure came from discipline. You didn't sit down and design layers. You asked for two things, "tell me when checkout fails" and "promise me the math is the math," and the structure leaked in from the rules.

Async leaks slow up through your code. Try/catch leaks might explode. Purity and named failures leak shape.

That's a leak worth having.

Parallelize more with BlockLease

Sat, 10 Oct 2026 20:21:31 +0000

One of the ideas in the scrml compiler that I am excited about, is something I call "BlockLease."

Safe parallelism in agentic code work forces concurrency to be locked to files. Two agents editing the same file just leads to re-creating every atomics problem devs have ever faced.

The design of this idea still has open questions. if you have any thoughts, drop me a line.

The problem

Parallel coding agents are kept safe by file. Each gets its own git worktree, and no two are sent to the same file. That gives up the common case: two agents editing different functions in the same module. In scrml it cost real time — two agents both edited emit-logic.ts, one landed a whole-file copy, and the other's work was silently reverted. The edits never overlapped. The isolation unit was just bigger than the work.

The idea

"if every block of code gets a unique ID... parallelism is no longer locked to disjoint files but to disjoint blocks... attach to blocks, no one else can edit those blocks..."

A block is a named definition — function, component, engine, type, channel — with the ID <relpath>::<name>. The ID already existed as a provenance anchor; block-lease reuses it as a concurrency token. One ID system, two jobs.

Block boundaries come from the compiler, not a separate parser. If two parsers disagree about where a block ends, two agents can each believe they hold the same lines. An early regex version assigned a four-line helper over 100 lines because a page's render markup followed it.

Admission is not landing

A lease decides whether two edits may proceed in parallel. It does not merge them, and text-disjoint is not the same as safe. Two branches can each add a write to errorMessage in different functions, merge without a conflict, and break the program.

What the compiler provides

scrml compile --emit-block-analysis writes each block's span and the cells it reads and writes:

${
  <errorMessage> = ""
  <okCount> = 0
  <quoteForm> = { originCity: "", weightLbs: 0 }

  function setError(m) { @errorMessage = m }
  function handler1() {
    @okCount = @okCount + 1
    setError("x")
  }
  function setCity(c)   { @quoteForm.originCity = c }
  function setWeight(w) { @quoteForm.weightLbs = w }
}

{ "id": "app.scrml::setError",  "reads": [],          "writes": ["errorMessage"] }
{ "id": "app.scrml::handler1",  "reads": ["okCount"], "writes": ["okCount"] }
{ "id": "app.scrml::setCity",   "reads": [],          "writes": ["quoteForm.originCity"] }
{ "id": "app.scrml::setWeight", "reads": [],          "writes": ["quoteForm.weightLbs"] }

Footprints are at field grain: setCity and setWeight write different fields of quoteForm and do not conflict.

They are also shallow. handler1 calls setError, which writes errorMessage, but handler1's footprint says only okCount. A non-empty footprint can still be incomplete. Until the compiler reports what a block writes through its calls, a sound check must reject any block that calls a helper — and most real handlers do.

Where it stands

Built: compiler-defined block identity and spans, field-grain read/write footprints, and a structured merge in giti that consumes them. Not built: the claim/release lease registry, leasing of render markup, and transitive footprints — the piece the rest waits on.

"scrml has subsumed block-lease"

What conflicts is not files but what an edit reads and writes. The compiler is the one component that knows that, so it is the one that has to answer.

Programming Is Magic: Bryan MacLee’s Journey Building scrml

Sun, 04 Oct 2026 22:32:36 +0000

Real developers. Real journeys. Real ideas.

Bryan MacLee is a truck driver specialising in the oil and gas industry, but programming is much more than a hobby for him. Driven by a deep love of JavaScript, frustration with web development's complexity, and an unconventional idea about how software should work, he is building scrml — an open-source compiled language for the web.

Interview & Story by Mehadi Hasan
CoderLegion Community & Editorial Team

It Started With “Hello World”

For Bryan MacLee, the answer to what initially attracted him to programming is surprisingly simple:

“Hello world.”

But explaining why programming became such an important part of his life takes a little longer.

Bryan describes programming as:

“The truest form of magic that we humans have ever created.”

It is a statement he stands by.

For him, programming is a recursively unfolding logic puzzle. You begin with a question, follow the logic, discover another layer, and continue uncovering how things work.

Even when a particular language or technology becomes repetitive, the underlying activity never really loses its appeal.

And that love of solving problems eventually led him somewhere unusual: instead of simply using programming languages, Bryan decided to build one.

A Truck Driver Building a Programming Language

Bryan works as a truck driver specialising in the oil and gas industry.

Outside that professional world, he spends his time exploring programming, JavaScript and the development of scrml.

He doesn't believe in the conventional idea of work-life balance.

As he puts it:

“Work and grow like progression is air. Laugh and love like the world ends tomorrow. To hell with balance.”

His oilfield work and programming are largely separate worlds. He doesn't claim that driving trucks has directly shaped his coding philosophy.

However, his enthusiasm for software and technology sometimes follows him into his day job.

One important difference is that Bryan has the freedom to choose what he works on and when.

He doesn't have a software manager demanding features or deadlines. He can explore ideas because they interest him, without having to turn every experiment into a commercial deliverable.

That freedom has helped him preserve something many developers struggle to maintain: his excitement about programming.

Loving JavaScript, but Disliking How It Handles the Web

Bryan's preferred programming language is JavaScript.

Not TypeScript.

JavaScript.

He loves how quickly he can write code, experiment and see whether an idea works. For prototyping, he considers it an excellent language.

But there has always been something that frustrated him.

JavaScript's role in interacting with the DOM and styling the web can become complicated, especially when building complex reactive components.

Bryan has experienced those frustrations firsthand.

Initially, he tried to solve them by building a library.

But as his ambitions grew, he began considering a framework.

That idea didn't last long either.

He felt frameworks could only go so far because they still operated on top of JavaScript, relying on conventions and abstractions that the underlying language itself didn't understand.

Around the same time, he developed an academic interest in Rust.

He admired its design, despite describing it as a beautifully hideous language.

That exploration prompted a question:

What if he could take some of the ideas he admired and build something around them?

The answer would eventually become scrml.

The Small Frustration That Started scrml

The origin of scrml wasn't a grand plan to create a new programming ecosystem.

It began with a small annoyance.

Bryan was working on a complex function and had written an expression whose result he wanted to reference.

But he couldn't think of a suitable name for a temporary local variable.

He sat staring at the cursor, increasingly frustrated.

Eventually, he typed a generic name and tried to move on.

But the interruption stayed with him.

He wanted to write an expression and reference its last fall-through value without having to invent a name for something that would only be used once.

As Bryan explains:

“I wish I could just write the expression and reference the last ‘fall-through’ value.”

And that was the moment scrml was born.

Not because he wanted to recreate Rust's enums or pattern matching.

Not because JavaScript state management was frustrating, although that was certainly part of his broader motivation.

It began because he wanted to stop naming one-time-use local variables.

Everything else, as he jokes, was a bonus.

What Exactly Is scrml?

scrml is a compiled programming language designed for web development.

It takes .scrml source files and generates HTML, CSS and JavaScript.

But its central idea goes beyond translating one language into another.

A single scrml file brings together:

Markup
Application logic
Styles
SQL

The compiler examines the whole program and determines how its parts relate.

It then separates client-side and server-side responsibilities and generates the necessary connections.

That includes server routes, fetch calls, CSRF handling and reactive dependency tracking.

Bryan wants developers to describe what their application should do without manually writing all the repetitive wiring required to make different parts communicate.

The language also introduces concepts that are central to his design philosophy:

First-class state
Exhaustive enum matching
State-machine constructs
Typed errors
A cohesive syntax across the application

Scrml is built to produce web technologies rather than operate as another framework sitting on top of JavaScript.

That distinction is fundamental to Bryan's vision.

One Language. One Compiler. One Understanding of the Program.

Bryan believes modern web development can become unnecessarily fragmented.

A typical project may involve separate tools for markup, styles, logic, compilation, server communication and other responsibilities.

Each tool sees only part of the source code.

That fragmentation is one of the problems he wants scrml to address.

His philosophy is:

“One walk. One language. One compiler that reads the markup, the logic, the styles and the SQL together, and actually understands how they relate.”

Because the compiler sees the whole program, it can generate connections that developers would otherwise have to create manually.

For example, when an application needs to communicate between the browser and server, scrml can generate the necessary routes, fetch calls and serialization.

Bryan also dislikes what he calls leaky abstractions and coloured functions.

His goal is to move responsibility into the language and compiler rather than leaving developers to manage conventions across multiple layers.

In his view, if the compiler understands the program, entire categories of mistakes can become impossible to express.

Making State a First-Class Concept

One of the ideas that influenced scrml was Bryan's exploration of state in functional programming.

He encountered a conventional definition of state as stored data, variables and conditions remembered by a program at a particular moment.

He wasn't satisfied with that explanation.

Instead, he developed his own description:

“A snap-shot of a data set, at the moment of observation.”

That led him to question why programming languages commonly provide logic and type systems but don't necessarily offer state as a first-class language feature.

Scrml incorporates state directly into its design.

For example, a state cell can be declared using a tag-like form and then referenced through the language's state syntax.

The compiler can track dependencies and manage the connections required for reactive behaviour.

Bryan is also working on stronger lifecycle and validation contracts, along with new approaches to state declarations.

These are part of his broader ambition to make the compiler responsible for more of the correctness guarantees.

Why Bryan Is So Serious About Dependencies

Bryan has a strong preference for minimal external dependencies.

He describes himself as someone who likes to build things himself and has a visceral dislike of not understanding the code in his own source tree.

He also sees automatically updating dependencies as a potential security problem.

That doesn't mean scrml prohibits importing external code.

Instead, Bryan wants imported code to enter through an explicit capability-gated mechanism.

His underlying principle is that a program should retain ownership and awareness of the code it uses.

He is particularly critical of developers introducing dependencies for trivial functionality.

His example is isEven.

For something that can be expressed through a simple mathematical operation, he questions why a developer would need to search the web for an external package.

For Bryan, fewer dependencies can encourage developers to understand what their applications actually contain.

Scrml includes a standard library intended to cover most common web application needs.

The goal isn't to eliminate useful code sharing, but to make dependencies more intentional.

“Assume the Compiler Works Perfectly”

Bryan's article Assume the compiler works perfectly addresses a particular challenge he has encountered when introducing scrml to other developers.

A couple of people had tried it and responded that nothing worked.

Bryan understands that this is a fair reaction, particularly when working with a new compiler.

But he wanted to ask a different question.

What if the compiler were already finished and worked perfectly?

Would developers actually want to write applications in scrml?

That is the question behind the article.

He isn't asking people to ignore technical problems or pretend the implementation is complete.

He wants to separate two questions:

Is the underlying language idea appealing?
Is the current compiler implementation mature enough to deliver it?

Building a compiler is a substantial undertaking, and Bryan knows the implementation still has work ahead.

But he wants feedback on the vision itself, not only on the current state of the tooling.

The Current State of scrml

Scrml is open source under the MIT licence.

At the time of Bryan's interview, the compiler was at version 0.8.0, running on Bun, and was not published to npm.

He has also reached an important turning point in its development.

The original TypeScript compiler prototype gradually became the product.

Over time, technical debt accumulated to the point where continuing to extend the existing implementation became increasingly difficult.

Rather than continuing to patch the old structure, Bryan has paused that compiler work and begun building a bootstrap approach.

The current TypeScript compiler is intended to compile a natively written scrml compiler.

In theory, this should help eliminate entire classes of bugs through construction rather than relying only on testing.

He is also working on standalone left-hand-side state declarations, as well as stronger lifecycle and validation rules.

It is a significant undertaking, but one that reflects his willingness to rethink the foundations rather than keep extending an architecture that no longer serves the language's direction.

Why He Still Loves JavaScript but Doesn't Want to Write It

Bryan's relationship with JavaScript is unusual.

He genuinely loves the language.

He appreciates its simplicity, speed and ability to support rapid experimentation.

But building scrml has changed where his excitement now lies.

He says that writing JavaScript has lost much of its appeal compared with the anticipation of writing applications in his own language.

He isn't less interested in programming.

His excitement has shifted from using existing tools toward creating a different way to work.

That enthusiasm is also what keeps him moving when scrml becomes difficult.

There are naturally moments of discouragement during a project of this size.

But the thought of eventually using the language he is building is a powerful motivator.

He intends to continue regardless of what others think.

Building a Language for More Than Himself

Bryan recognises that he doesn't need a production-level compiler simply to enjoy experimenting with his own ideas.

He could build a much smaller tool and still benefit from it personally.

But that's not the entire reason he's building scrml.

He believes the ideas have value for other developers.

He wants people to use it, question it, debate its assumptions and help improve it.

Scrml is released under an open-source MIT licence, and Bryan doesn't see it as something that belongs exclusively to him.

His ambition is to make it a shared project.

“I don't view this as ‘my’ language. MIT, open source, I gave it to the world.”

For Bryan, the value of scrml is directly connected to the number of people willing to engage seriously with its ideas.

He wants developers to challenge his assumptions and help make the language better.

What Would Success Look Like?

Bryan's definition of success is refreshingly modest.

He doesn't need thousands of users or a large company to feel that the project has been worthwhile.

His ideal milestone is simply hearing from one real developer who enjoys using scrml.

As he puts it, success would be receiving an email or message from someone saying:

“I enjoy writing scrml.”

That alone would make the work worthwhile.

He hopes scrml may eventually stand alongside other interesting programming languages, but he doesn't measure its value only through popularity.

The immediate goal is to build something genuinely useful and invite other developers to help shape it.

The Freedom to Keep Programming for the Right Reasons

One of the most interesting parts of Bryan's story is that he hasn't followed the conventional professional software-development route.

He isn't building scrml because an employer assigned it to him.

He isn't chasing a job title or trying to meet a commercial delivery deadline.

He codes when and what he wants to.

That freedom has helped him avoid becoming burned out or jaded about programming.

He also doesn't force himself to read documentation or follow technologies that don't interest him.

Instead, he can focus deeply on the ideas that capture his attention.

That doesn't mean the journey is free of frustration.

Building a programming language is difficult, and Bryan is candid about the challenges.

But his motivation comes from genuine curiosity rather than external pressure.

It is a reminder that unconventional paths can provide their own advantages.

Advice for Developers With Unusual Ideas

Bryan's advice to someone with an unconventional programming idea is direct:

“If you have an idea, and you think it is worth attention. Scream it from the rooftops.”

He doesn't believe that a lack of a traditional background, job title or established resources should automatically stop someone from pursuing an interesting idea.

Ideas should be exposed to discussion.

They should be questioned.

They should be challenged.

And sometimes they should be corrected.

Bryan sees correction as an opportunity rather than something to fear.

The worst outcome, in his view, is that someone points out where your assumptions are wrong.

That is far better than allowing insecurity to prevent you from trying.

From Truck Driver to Language Creator

Bryan MacLee's journey is not a conventional story about becoming a software engineer and climbing a corporate career ladder.

It is about someone who loves programming enough to question the tools he uses and attempt to build something different.

His journey began with JavaScript, frustration with web development's complexity, curiosity about language design and one seemingly insignificant problem: naming a temporary variable.

That small frustration grew into scrml, a compiled language with ambitions around state, type safety, application structure and compiler-driven correctness.

The implementation is still evolving.

The architecture is being reconsidered.

And the project needs developers willing to test, question and contribute.

But Bryan's motivation remains clear.

He isn't building scrml simply to prove that he can build a programming language.

He's building it because he believes programming can be made better — and because the act of creating software is, to him, one of the most remarkable things humans have ever learned to do.

About Bryan MacLee

Bryan MacLee is a truck driver specialising in the oil and gas industry and an independent programming-language developer.

He is the creator of scrml, an open-source compiled language for web development that generates HTML, CSS and JavaScript.

His preferred technologies include JavaScript, HTML and CSS, and his interests include language design, compiler development, state management and reducing unnecessary complexity in web development.

Connect with Bryan MacLee on CoderLegion.

Bryan's story is a reminder that a good idea doesn't need to come from a conventional career path.

Sometimes it starts with a simple frustration — and the willingness to ask:

Interview & Story by Mehadi Hasan

CoderLegion Community & Editorial Team

Arrays are dumb. So are tuples.

Tue, 29 Sep 2026 14:43:13 +0000

The array/tuple question was never meant to be a long running thing. And as it often happens, the solution was right there in front of me the whole time.

Arrays are intuitive, fast, and let you do (basically) anything. Therein lies the problem with them, no type-constraint, no tracking (other than what you keep in your head).

Tuples are almost exactly the opposite. Powerful, dependable (in and of themselves), type-safe at the position level. But they are awkward, and tend to make code that depends on them, more brittle.

When a debate goes back and forth multiple times with NO NEW INFORMATION being submitted; it tends to devolve into an interminable loop. The only way to break the cycle is to add data, or perspective. The second is honestly the more powerful, by far.

So, what is the perspective that this question is inspected from? "a programming language needs arrays, tuples, or both." There, simply by stating what the subject is in clear terms, we can start to see that the problem is in the perspective itself.

"A programming language needs an ordered-sequence data-structure" (hyphens were hand typed, mmm). Now just look at that! The solution practically bites you on the nose.

Don't use arrays or tuples.

A "tape" is a "constrained by use-case" data sequence. You can think of it as an array with a la carte permissions. With no permissions, a tape explicitly declared will remain exactly that forever.

<primes:int[]=[2, 3, 5, 7]/>

@primes.push(11)                       // error: length is fixed
@primes[0] = 1                         // error: positions are read-only
@primes = [1, 2, 3]                    // error: replacing the whole thing is its own permission
const big = @primes.map(p => p * 10)   // fine: map returns a new value

The sequence itself is frozen: no appends, no removals, no reordering, no swapping one element for another. The elements are exactly as frozen as their own type says. If the type of the thing on the tape has a writable field, that field is writable, tape or no tape. Same rule, all the way down.

<todo:struct>
    <title:string=""/>
    <let done:bool=false/>       // this field grants its own write
</>

<todos:todo[]=[...]/>            // a tape with no permissions

@todos[0].done = true            // fine: judged by `done`, not by the tape
@todos[0].title = "x"            // error: title is locked
@todos.push(t)                   // error: the tape is frozen

The obvious way to build this is a list of allowed methods: this tape may push, that one may pop. That breaks immediately. @log = @log.slice(1) throws away the first entry using nothing but a non-mutating method and an assignment. No banned method was called. So a tape's permissions aren't a list of methods, they're axes: how the length may change, where changes may happen, whether a position may be rewritten. The compiler judges every write by what it DOES to the value, not by how it's spelled. slice(1) is a change at the front. If the tape doesn't allow front changes, that line doesn't compile.

Here's an audit log. Free length, changes only at the end, and nothing else:

type Entry:struct = { at: number, actor: string, action: string }

<audit:Entry[free, end]=[]/>

@audit.push(entry)                          // fine
@audit = [...@audit, entry]                 // same edit, different spelling: fine
@audit.shift()                              // error: a change at the front
@audit = @audit.slice(1)                    // error: still a change at the front
@audit = @audit.filter(e => e.actor != "x") // error: a removal from anywhere
@audit = []                                 // error: a replace
reset(@audit)                               // error: reset is a replace too

No statement anywhere in the program can remove or rewrite an entry, however it's spelled. That log is provably append-only, and the proof costs you one line.

The permissions are part of the tape's type, so they travel. A function only gets to do what its parameter says:

fn pushEdit(s: Edit[end], e: Edit) -> Edit[end] {
    return [...s, e]             // the only thing this function CAN do to `s`
}

<undo:Edit[end]=[]/>
@undo = pushEdit(@undo, e)       // fine: the compiler reads the body and sees an append at the end

There's no "all permissions" switch. A fully mutable tape has to name every axis it wants. An all-grant is a leaky abstraction, unacceptable.

<todos:Todo[free, anywhere, writable, replace]=[]/>

Every axis named. No shorthand. That's the point.

The tape is specified in the scrml language spec (§66.12) and is being built into the new compiler now. It is not in the shipping compiler yet, and the permission syntax shown here is the proposed spelling.

Assume the compiler works perfectly

Wed, 23 Sep 2026 19:01:05 +0000

When developers look at a new programming language, they usually test it by running the compiler. That makes sense, since the compiler is the only part you can actually run. But it hides a distinction that matters a lot for an early stage language: the language and its compiler are two totally different things

A programming language is a design. It's a set of rules for what programs look like, what they mean, and what the language refuses to allow. It covers the abstractions, the defaults, and the tradeoffs.

A compiler is a program that implements that design. It turns source text into something that runs. It has bugs, missing features, slow spots, and confusing error messages. Those can all be fixed without changing the language.

For an established language, the difference is mostly academic. But, for a new language, the distinction is incredibly important.

A new compiler is always rough. It will have gaps, odd edge cases, and diagnostics that need work. Feedback about those is real and welcome, but it answers: does this implementation work yet?

The important question: is this language worth building a compiler for, at all? A turd can't be polished into being, not a turd.

Language feedback judges the design, regardless of compiler functionality.

When I ask what people think of scrml, this second kind of feedback is what I'm after. Compiler bug reports help and I'll keep fixing what they find. But the question that decides whether scrml should exist is a language question:

Assume the compiler works perfectly. Is this a language you'd want to write?

"No, because…" is just as valuable as "yes," as long as the reason is about the design and not the current compiler build.

But, by far, the most valuable feedback is: "I think this feature is implemented incorrectly, and I have an idea to fix it."

The value of this last statement is not in the 1 idea of 1 feature of the language. It is that a second human being has actual interest in building this thing with me!

I am not special. I am not a beautiful, unique snowflake. I am the same "all singing, all dancing crap of the world" as everyone else. I am not especially capable of designing a programming language.

What I do have, that does qualify me, to at least submit my opinion on the matter; is a genuine and abiding love of programming. It is a thing that I care about deeply. It is a thing that I want to nurture and improve, if I can.

If you feel similarly, join me. Our ideas will certainly be better than my ideas.

I am Jack's ``

Tue, 15 Sep 2026 13:22:17 +0000

I am Jack's <engine>.

Without me, Jack's application has values without a place.

Jack declares me once. I am a singleton. Every part of his program that reads my cell is
reading the same me.

${
    type Order:enum = { Cart, Paying, Paid, Shipped, Refunded }
}

<engine for=Order initial=.Cart>
    <Cart    rule=.Paying          : "Your cart.">
    <Paying  rule=(.Paid | .Cart)  : "Talking to the bank.">
    <Paid    rule=.Shipped         : "Thank you.">
    <Shipped rule=.Refunded        : "On its way.">
    <Refunded                      : "We are sorry.">
</>

That is all of me. Jack's order, the message, and the arrows.

I declare Jack's variable for him. He never writes @order. He receives it.

Every variant has a line. That is not tidiness. It is the deal.

Jack has not built the refund screen yet. He deletes <Refunded> from my body.

He does not delete it from Order. He removed the room, not the guest.

error [E-ENGINE-STATE-CHILD-MISSING]: <engine for=Order> body is missing a state-child for variant .Refunded.

Somebody is going to get a refund.

I do not know who. I know there will be a place for them to stand.

The rule= is the part Jack underestimates. It is not documentation. It is a contract on
writes.

Jack writes this at 2am:

<Cart rule=.Paying>
    <button onclick=${ @order = .Shipped }>Check out</>
</>

He is inside <Cart>. I know precisely where he is standing. So I do not wait for a test,
or a user, or a chargeback:

error [E-ENGINE-INVALID-TRANSITION]: @order = .Shipped inside state-child <Cart> is invalid. <Cart>'s rule=.Paying — only .Paying is reachable.

Jack shipped an order that was never paid for. He shipped it in a text editor, to nobody,
and I was the only one who saw.

That is the whole incident. No page, no ticket, no customer.

Jack closes the error and goes to bed.

Before me, Jack wrote this.

const [isPaying,   setIsPaying]   = useState(false);
const [isPaid,     setIsPaid]     = useState(false);
const [isShipped,  setIsShipped]  = useState(false);
const [isRefunded, setIsRefunded] = useState(false);

// four hundred lines later
setIsShipped(true);

Four booleans. Sixteen combinations. Five of them are an order.

The other eleven are paid and refunded and never shipped. Shipped and still sitting in the
cart. They are exactly as easy to write as the real five, and nothing tells Jack which is
which. He carries that list in his head, in every file.

I do not refuse the other eleven. There is no way to say them.

Jack could reach for a reducer. A reducer gives Jack his one variable back. It does not give
him the arrows. It will take a SHIP action while the order is still in the cart, hand back
an order that is shipped, and type-check on the way out.

I am Jack's raging bile duct!

Jack has two ways to move. Both of them go through me.

@order = .Paying            // a write. checked, and quiet when it holds.
@order.advance(.Paying)     // an assertion. this must hold, or halt.

The difference is not whether I check. It is what Jack means by failing. A write that
cannot happen is a bug. An assertion that cannot happen is a belief Jack held that was
wrong, and he wants the noise.

There is no .tryAdvance. One was proposed and refused, on the grounds that silent failures
hide bugs.

Writing Jack's current state back onto itself does nothing at all. Re-asserting where you
are is not travel.

I am not Jack's validation. Validation arrives after Jack has already built the wrong thing.

I am the shape of what Jack is permitted to build.

An honest question

Sun, 13 Sep 2026 01:37:00 +0000

To whom it may concern,

The articles that I publish. The smack talking that I engage in, here or on X (more likely). That is all an attempt at engaging anyone, with an opinion and the junk to back it, in a conversation about what programming should look like in the next iteration.

There are those out there that would give an opinion on how to program for the hardware. TBPC, I have the utmost respect for these individuals. It is not an easy thing, to try and tell the world how an entire industry should change. You tend to stand alone, for the most part.

That is why I have been so flagrant with my goading. I am not trying to tell the world that THIS is how it should be done. I am asking a question. Is this closer to the shape of the next version of what we do?

I use "we" loosely here, but tighter than the times might suggest.

I am genuinely happy for the "vibe coders" that make it some where. I really am. I have absolutely no desire to diminish the hopes and happiness of any human being.

But that is not who I am speaking to here.

I am speaking to the ones that still remember their "hello world" moment. Those that got the answer off of stack overflow, and then hacked, and reworked the code until they not only understood it, but could improve on it.

The ones that, as they wrote out an expression, had a thought about how that act could be improved.

If that is you, I am ready to talk. Tell me I wrong, please. Question why the syntax looks the way it does. offer an alternative.

I can't freaking wait to listen to you explain why my assumptions were wrong, and to defend my choices on syntax or semantics. Not because I want to flex, because I want to grow, to improve, to progress.

Scrml is cool. What is way cooler, is that there is an oportunity here. One that would allow us as a self-proclaimed "coder," (whatever that means) to actually have a say in what we try next. The only thing that matters to me is the conversation and controversy. Without which, scrml will never be more than a hobby project. And that is fine, wonderful infact. It means that I was off base. No big deal, I've missed the mark before. I'll move on.

This is not bating. I mean every word.

How can srcrml be better? Let's have a conversation.

If you made it this far, than either you are reading just to finish. Or you have recognized a kindered spirit and know for a fact, that I am speaking to you.

And if you are the latter, say hi.

I am Jack's `match`

Tue, 08 Sep 2026 14:37:06 +0000

I am Jack's match.

I am the question Jack asks about a value that could be more than one thing.

He has an order. It is exactly one of five things, and he wrote the list himself.

type Order:enum = { Cart, Paying, Paid, Shipped, Refunded }

There are two of me. Jack does not pick between us — where he puts me decides which one he
gets.

In his markup, I draw.

<match for=Order on=@order>
    <Cart     : "Your cart.">
    <Paying   : "Talking to the bank.">
    <Paid     : "Thank you.">
    <Shipped  : "On its way.">
    <Refunded : "We are sorry.">
</>

In his logic, I answer.

fn label(o: Order) -> string {
    return match o {
        .Cart     :> "in the cart"
        .Paying   :> "with the bank"
        .Paid     :> "paid for"
        .Shipped  :> "on its way"
        .Refunded :> "refunded"
    }
}

Two shapes. One of me underneath — the same tree, the same count. The only thing that
changed is whether Jack wanted a screen or an answer.

Jack added .Refunded to that list last month, because a customer's bank called.

He did not go looking for the places that needed updating. He did not have to.

error [E-TYPE-020]: Non-exhaustive match over enum type Order. Missing variants: ::Refunded. Add arms for the missing variants, or add an else arm to handle them all.

Every place in his application that asks what an order is, and has no answer for a refunded
one, stopped the build. I name the file. I name the variant. I name both remedies.

Jack was annoyed. The alternative was four screens quietly rendering nothing on the worst
day of a customer's week.

I am Jack's complete lack of surprise.

Jack can finish me with else, and I will take everything he did not name.

.Shipped :> "on its way"
else     :> "something else"

That compiles. It also costs him the paragraph above: the next variant lands in else, the
build stays green, and I say nothing. It is a real trade and it is sometimes the right one.
It is only a mistake when Jack makes it without knowing he made it.

If he names all five and writes else anyway, I tell him that too.

warning [W-MATCH-001]: Wildcard _ arm is unreachable. All variants of Order are already covered by explicit arms. Remove the _ arm.

One day Jack notices his five arms are not five pictures.

.Cart never goes straight to .Shipped. There is an order to them, and he has been holding
it in his head this whole time.

When that day comes, he changes one word.

<engine for=Order initial=.Cart>

The arms do not move. The same five lines, untouched.

He has stopped asking what his order is, and started declaring where it may go.

That is a different organ.

I am Jack's ``

Tue, 08 Sep 2026 05:07:54 +0000

I am Jack's <program>.

Jack declares me once, in one file, for the whole application. Everything he writes lives
inside me — his markup, his logic, his styles, his database.

There is a line running through me. On one side is Jack's server. On the other is a browser
Jack does not own, cannot see, and should not trust.

Jack does not draw that line. I do.

Everything Jack writes runs in the browser. That is the default, and it holds until I find a
reason to move it.

<program title="Jack's Store">
    import { hashPassword } from "scrml:auth"

    <password> = ""

    function signUp(pw: string) {
        const hash: string = hashPassword(pw)
        println(hash)
    }
A
    <h1>Sign up</>
    <input type="password" bind:value=@password/>
    <button onclick=signUp(@password)>Create account</>
</program>

I found a reason. signUp reaches scrml:auth, and scrml:auth handles things that must
never arrive in a browser. So signUp is not a browser function any more.

Jack gets two files he did not ask for. This is what ships to the browser:

signUp_4(pw) { ... fetch("signUp_1", "POST", _scrml_body) }

And this is what stays behind:

import { hashPassword } from "./_scrml/auth.js"

The password is hashed in a process Jack controls. The browser gets a POST and a promise.

Jack never typed the word server. There was a keyword for it once. It is deprecated now.
Everything it used to tell me, I work out on my own.

Jack thinks of me as one thing per application. I am one thing per boundary.

Put me inside myself, and the inner one is not a section of Jack's app. It is a separate
execution context, with its own scope and its own lifecycle.

<program name="compute">
    export function withTax(n: number) -> number { return n * 1.08 }
</>

What that becomes depends on the properties that Jack assigns to me. A name= and it is a web worker. Add a
lang= and it is a subprocess speaking another language. Add mode="wasm" and it is a
WebAssembly module. Give it a route= and it is an endpoint at a fixed address — the one
shape Jack has to name himself, because the thing that will call it is not his.

Every other address in his application is mine. He has never seen one.

Same element. Four different machines.

None of Jack's things reach inside it. Not a binding, not a type, not an import. If he wants
the inner one to know his tax rate, he sends it.

A boundary that leaks is decoration.

The first time Jack wrote that function, it read @password out of the air.

error [E-REACTIVE-003]: Server-escalated function signUp reads the client-side reactive variable @password. ... this read lowers to _scrml_body["password"], which the client stub never sends, so it resolves to undefined at request time.

He had written a function that reached across a line which did not exist when he started
typing it. I moved the function. Jack did not move with it.

So I told him where the seam goes: pass the password in, and I will carry it across. That is
the version above. It cost him one parameter.

Consider what I would be if I got this backwards.

Jack's hashing, and the secret it holds, compiled into a file that every visitor downloads.
A green build. No warning. Nobody learns about it until somebody does.

I am Jack's cold sweat.

So when something resists classification, I put it on the server. Wrong in that direction
costs Jack a round trip. Wrong in the other direction costs him the secret.

Jack thinks of me as the place his application starts.

I am the place it is divided.

scrml is pre-1.0. The server/client split in this piece ships today — the two bundles above
are real compiler output. Nested execution contexts are specified and not yet built: the
boundary described here is the language's, and the compiler is still catching up to it.

If You Give a Dev an Enum, then

Mon, 31 Aug 2026 17:17:08 +0000

If you give a dev an enum, they're going to ask if they can match on it.

When you let them match on it, they'll want to know they got it all.

So the compiler counts. And it finds one.

It says E-MATCH-NOT-EXHAUSTIVE, and it names the variant: .Empty.

And then they'll add the arm.

<match for=Phase on=@phase>
    <Idle>      <button onclick=load()>Load</button>   </>
    <Loading>   Loading...                             </>
    <Error msg> <div class="err">${msg}</div>          </>
    <Empty>     No rows yet.                           </>
    <Success count> Got ${count} rows                  </>
</>

Then they'll look at those five arms and notice something.

.Idle doesn't go to .Success. It goes to .Loading first. See, it says so.

So then they'll want the arrows. You give them rule= and <engine>.

So they'll do the whole rewrite.

<engine for=Phase initial=.Idle>
    <Idle rule=.Loading>      <button onclick=load()>Load</button>   </>
    <Loading rule=(.Success | .Error | .Empty)>   Loading...         </>
    <Error msg rule=.Loading> <div class="err">${msg}</div>          </>
    <Empty>     No rows yet.                             </>
    <Success count> Got ${count} rows                    </>
</>

Every body is untouched.

One word on the wrapper. Where it starts. Where each may go.

And now that it knows where it starts and where it may go,

it simply will not let them go anywhere else.

Then in a click handler, they'll write @phase = .Success.

Straight out of .Idle. The happy path was right there.

The compiler says no. And quotes the rule they wrote a bit ago.

They'll be annoyed, about four seconds. Then they'll realize that would have shipped.

Once the states are honest, they'll want something to happen.

Fire the analytics. Focus an input. Start a timer.

<onTransition from=.Loading to=.Success>
    ${ analytics.track("load.success") }
</>

And that effect wants data. So they'll write the query out.

const rows = ?{ select * from items }

And they'll wonder how to tell it this part is on the server.

So you tell them that's the compiler's job.

They'll type await. It won't be there.

Then they'll think about the query coming back empty.

Not empty empty. Not there empty. The row that wasn't.

That one has a name. It's not. And then you ask them a few questions.

Is "" absent?

No. It's a string. You have one.

Is 0?

That's a number.

Is []?

No. It's an array. It's just short.

Absence is absence and emptiness is emptiness. Only one of them is not.

given rows :> {
    @phase = .Success(rows.length)
}

A user will need to type something in. Then,

The dev will declare the field with what's true:

<signup>
    <name  req length(>=2)> = <input type="text"/>
    <agree req>             = <input type="checkbox"/>
</>

<errors of=@signup.name/>
<button disabled=${!@signup.isValid}>Sign up</button>

Nobody declared @signup.isValid.

They'll want to show the errors, so they'll ask where the error strings live.

And here is where it gets funny.

They aren't strings. You say.

@signup.name.errors[0] is .Required. Or .LengthFailed(predicate).

The failure has a tag and a payload.

The message can come later. Which means the dev is holding a value

with a fixed set of named cases. And a payload on some of them.

So the dev now has an enum...

A struct is a data strucure, of course of course

Wed, 26 Aug 2026 21:09:52 +0000

When I started designing this language, I had a lot of fundamental decisions to make. Among those, one of the easiest was whether or not to allow virtual functions in scrml structs.

If I had chosen to include virtual functions; I would have just called these data strctures objects.

If you were paying attention, you might see why.

A struct is a data structure. Plain and simple. But, you see, it is within that simplicity, the power is made plain.

Lets define a unit of data as a value over over a type ( x/T ). Some would claim that it is state over type. Philistines!

State is data that is presently being witnessed.

While this might seem like a trivial distinction. The real differentiation comes from the realization that state is not witnessed in piecemeal. it is accepted as a whole, or thrown out as invalid state.

State is, therefore, immutable by nature.

So then, what of structs? I'll cover that in the next article "State. Why its not data."

Just kidding. I hope this next part is becoming more obvious.

So are struct mutable? ... Depends. But, let the default be: the node-tree structure should be immutable. Hence, a user definable structure. the values should mostly bi mutable, with each node mutation re-validated against it's type (or predicate if run-time validation is reqd)

Simple. And because it's simple, we can analyze it, exhaustively.

Enter enums, engine, and other super-powers that "objects" just can't match .)

I have a conffession to make

Wed, 26 Aug 2026 13:03:36 +0000

I am not exactly sure when this language really started to become writable. I imagine I am one of the few, if not the only guy to build a legitimately usable programming language without ever really having written it.

Don't get me wrong. I have written thousands of lines of scrml. But only in the context of describing some part of the language to agents. I had yet to actually open up NeoVim to a blank file and try you write a <program>.

After only about 8 loc, I had found 2 bugs. One of them significant. Function argument types were not checked against their parameter types. I mean, at all!

WTF?! The type system is the biggest component of the current compiler and it doesn't check types?!

Turns out, not as dramatic a bug as I had originally thought. While the type and state systems are tightly woven together; the logic system, apparently didn't get as much attention. Rectifiable.

But I do feel It's important to call this kind of thing out because it is a perfect example of what we will, certainly, continue to run into during the infant stage of this fancy new tool.

Not to drum behind the party beat, but, pretty sure we will still need human beings deep in the loop for a while.

And also a conditional apology. If any squishy brain out there has ever downloaded scrml and actually gave it a try; only to find out that it is still quite broken, in terms of human use...

I am sorry