Languages

What this tool can be pointed at and what it cannot, language by language, for a reader who has one in hand and wants to know before writing a header. Two lists, fit and unfit, and in front of them the seven properties of the tool that every verdict rests on, so that a language not listed can be scored the same way. This page is a survey in the sense prior-art.md is, and like that page it outranks nothing: REFERENCE.md states the properties, direction.md argues for why the walls stay where they are, and where this page and the code disagree the code is right. Written 2026-09-06. Every verdict names the property it rests on, and the files that decided them are kept in docs/languages/ and run by the suite: the last section, Run, not reasoned, shows each with its transcript.

What decides it

A language is fit when the programs people actually write in it can be read whole, or when the subset people would want is readable and the rest is a wall the file can name in its own closing note, the way examples/python.mx does. It is unfit when the ordinary program meets a wall: when reading it would mean, in direction.md's phrase, becoming a different tool. Unfit is a statement about the whole language. A subset of nearly anything reads, and the fit list says where the useful subsets stop.

Seven properties decide it. Each is a fact about the tool, stated where the reference states it, and each has a list of languages it settles.

1. A rule sees its own pattern and nothing else. No symbol table, no types, no scope. That is the property direction.md is built around, and it is the wall at x * y in C, at Banner; in Pascal, at the first assignment in Python that C wants declared, and at any output that needs a type the source did not spell. Collections (REFERENCE §8.4) reach the one case that needs no reading back: a head that is the aggregate of its body.
2. The lexer is regexes and quoted words, and its only state is the indent stack. REFERENCE §6.1. At each position the longest class match and the longest word are taken, the class wins a tie, and nothing that came before changes what a character means. Four things follow, and the first three are run below, in case.mx, nest.mx and tail.mx:
   • Matching is case-sensitive, so BEGIN and begin are two words and a case-insensitive language reads only in the case its header spelled.
   • A block comment does not nest: /* a /* b */ c */ closes at the first */.
   • A class that could match the rest of a line swallows the keyword in front of it, since it is the longer match, so no rule can read a line whose tail is another language: a Dockerfile's RUN, a Makefile's recipe.
   • Anything the lexer would have to decide is out: whether / begins a regex or divides, where a heredoc ends, what ${ nests inside a string, what column a token is in, whether the text after < is a tag name or the words of a paragraph. xml-text.mx below is the last of those.
3. A list is separated by a word, or it is not read. A repeated group whose turns are expressions needs a sep word to know where one turn stops, and whitespace is never a word. A rule that begins with a hole must have a word second, so a led rule cannot be two holes. Between them this rules out juxtaposition: f x y as application, (f x (g y)) as a call, a b c as a command line, ab as concatenation. It is the property that surprised this page, and it puts the smallest grammar on it in the unfit list. lisp.mx and atoms.mx below are its two sides.
4. A newline is whitespace or a separator, and only a declared bracket suspends it. A language whose statements end at a line break reads under @separator "\n", and a call wrapped onto a second line reads only between the sides of an @bracket, because the lexer knows what a bracket is from that line and from nothing else. A line that continues past a bracket, or by a rule of the language the file cannot spell, such as a backslash or an open operator, is a separator where the language has none. A language that ends statements with a word does not care. toml.mx and toml-wrapped.mx below are the two sides of the line.
5. A block is braces, a pair of words, or one shape of indentation. @separator … indent and the block kind, REFERENCE §4.3, are Python's shape: a deeper line opens a block and a shallower one closes it. A layout rule that opens a block at the column of the next token, or a language where the tab is not eight columns, is not that shape.
6. Text mode is a scan, and what it knows of a language is what the file declares. REFERENCE §7 and §3.11. A rule fires where its words match and everything else passes through, which is the island grammar every tool that works on real code has, and since 2026-09-06 it has the three things those tools know: where a @token class matches the scan moves by the token, so a rename over err leaves stderr alone and a string or a comment declared as a class is passed over whole, and a hole stops only where the @bracket pairs balance, so a hole over f(x, g(y)) is all of it. What it still lacks is a column: a construct defined by its indentation has nothing to measure it. So text mode is for markup and for a rewrite over a real file, and a formatter would want the columns it does not have.
7. Output is text, built upward, and any language can be written. The question on the output side is never the grammar, since there is none to satisfy; it is whether the source carries what the output wants. BASIC's sigils carry a type and Python's annotations carry one, and Pascal's writeln carries nothing, which is why stage 1 stopped there. A code template has indent(s, n) for an output whose blocks are indentation.

Two readings of the same list. The properties are limits of the tool as it stands, and most of them are limits by decision: 1 is what keeps a rule composable and @use-able, and 2, 3 and 4 are what keep the lexer something a header can fully declare. None of them is merely unbuilt: the wrapped line was, until 2026-09-07, and landing it moved the two verdicts it had named and no other. Nothing else on the roadmap would move one.

Fit

The input side. Each row says how far the tool reads and which property stops it, and a row that says whole means an ordinary program in that language reads without a wall.

And two rows for reading a real file rather than one written for a grammar, since that is the question a reader with a codebase is asking:

Unfit

The whole language, as its programs are written. Each row names the property and the construct that meets it, and where a subset or a text-mode rewrite is still worth having, the row says so.

As an output

Property 7: any language can be written, and the examples deliberately write several. What the suite has compiled, assembled or run: C, in every test that compiles what it produced, arm64 assembly on a CPU, and Python's own source through python3 beside the C made from it. What the examples write and the recorded .out checks: JavaScript, HTML, Pascal, and Proto's Solveig.

What decides an output is what the source carries, and the rows above say where a source stops carrying it. Three shapes of output are worth naming because each needed a mechanic:

• An output with a head that its body determines, C's declarations, an include only if something prints: collections, contribute and splice.
• An output that is not shaped like its input, a sequence with labels where the input was a tree: fresh names, {~L}, and @template. Stage 2.
• An output whose blocks are indentation, Python or YAML from a brace language: indent(s, n) in a code template, and only there. A string template cannot indent what it splices.

And the jobs, not the languages

The lists above are by language, and the question is often by job. The same seven properties, read that way:

Run, not reasoned

The files that decided the verdicts above, kept beside this page in docs/languages/, each a header and a few lines of body. Every transcript here is run by tests/docs.sh against what it claims to print, so a change to the lexer or to groups that moves a verdict turns this page red rather than stale. POSTMORTEM.md 25 is why: two verdicts on the first draft were reasoned from the reference and both were wrong, and the six-line files that refuted them had been thrown away. Grouped by the property each one runs, then the fit rows that name a file.

Property 2, case. The header spells begin and the body writes BEGIN, which is a name token and not that word, so the statement it opens has no rule:

; case.mx -- property 2: matching is case-sensitive. The header spells
; `begin`, and the body's `BEGIN` is not that word.

@token number "[0-9]+"
@token name   "[A-Za-z_][A-Za-z0-9_]*"
@separator ";" => ";\n"
@syntax "begin" b:stmts "end"  => "{{ {b}; }}"
@syntax "print" x              => "print({x})"
@end
begin print 1 end;
BEGIN print 2 END

$ mx docs/languages/case.mx
mx: docs/languages/case.mx:11: no rule reads 'print' here

Property 2, a block comment does not nest. The first */ closes it, and c */ 1 is read as the body:

; nest.mx -- property 2: a block comment does not nest. The first `*/`
; closes it, and what follows is read as the body.

@token number "[0-9]+"
@comment "/*" "*/"
@syntax "print" x  => "print({x})"
@end
print /* a /* b */ c */ 1

$ mx docs/languages/nest.mx
mx: docs/languages/nest.mx:8: nothing here is anything this file declared: 'c */ 1
'

Property 2, a class that can match the rest of a line swallows the keyword in front of it. RUN apt-get update is one shell token, longer than the word RUN, so the rule never fires and the token stands for itself. This is the Dockerfile, and it is make's recipe line:

; tail.mx -- property 2: a class that can match the rest of a line is the
; longest match and swallows the keyword in front of it. The rule never
; fires, and the token stands for itself.

@token shell "[^\n]+"
@separator "\n"
@syntax "RUN" s:shell  => "sh -c '{s}'"
@end
RUN apt-get update
RUN make check

$ mx docs/languages/tail.mx
RUN apt-get update
RUN make check

Property 2, a token that exists only by position. XML character data stands between a > and a <, and a class declared for it matches after < as well. In a bare tag the two classes tie on the tag name and the earlier declaration wins, so <p> alone reads by luck; the first attribute makes the character class the longer match, and the tag name is gone:

; xml-text.mx -- property 2: character data is a token only by where it
; stands. A class declared for it matches after `<` as well: in a bare tag
; it ties with the tag name and the earlier declaration wins, so `<p>` alone
; reads by luck, and the first attribute makes it the longer match.

@token name   "[A-Za-z_][A-Za-z0-9_-]*"
@token string "\"[^\"]*\""
@token chars  "[^<>]+"
@syntax "<" n:name [ a:name "=" v:string ]* ">" c:chars "</" m:name ">"
    => "{n}({c})"
@end
<p class="lead">some words</p>

$ mx docs/languages/xml-text.mx
mx: docs/languages/xml-text.mx:12: no rule reads 'p class="lead"' here

Property 3, a list separated by whitespace is not read. The one rule Lisp needs is refused at the header, because a turn that is an expression has to be told from the next by a word, and whitespace is skipped before a word is looked for:

; lisp.mx -- property 3: a repeated group whose turns are expressions needs
; a `sep` word, and whitespace is never one. Refused at the header.

@token number "[0-9]+"
@token name   "[A-Za-z_][A-Za-z0-9_]*"
@syntax "(" f:name [ x ]* ")"  => "{f}({x})"
@end
(f 1 (g 2) 3)

$ mx docs/languages/lisp.mx
mx: docs/languages/lisp.mx:6: a repeated group that ends in a greedy hole and begins with a hole needs a 'sep' to know where one turn stops

Property 3, the other side. A turn that is one class token needs no sep, since it ends where the token does. A list of atoms reads; a nested list is the file above:

; atoms.mx -- property 3, the other side: a list of class tokens needs no
; `sep`, since each turn is exactly one token. Atoms read; a nested list
; would not, see lisp.mx.

@token number "[0-9]+"
@token name   "[A-Za-z_][A-Za-z0-9_]*"
@syntax "(" f:name [ x:name ]* join ", " ")"  => "{f}({x})"
@end
(list a b c)

$ mx docs/languages/atoms.mx
list(a, b, c)

Property 4, before the wall. A fixed-shape format under @separator " ", a statement to a line:

; toml.mx -- a fixed-shape format under `@separator "\n"`: a statement on
; its line reads whole. Compare toml-wrapped.mx.

@token number "[0-9]+"
@token string "\"[^\"]*\""
@token name   "[A-Za-z_][A-Za-z0-9_-]*"
@separator "\n"
@syntax "[" t:name "]"                        => "section {t}"
@syntax k:name "=" v   10                     => "  {k}: {v}"
@syntax "[" [ x ]* sep "," join ", " "]"      => "list({x})"
@end
[server]
port = 8080
hosts = ["a", "b"]

$ mx docs/languages/toml.mx
section server
  port: 8080
  hosts: list("a", "b")

Property 4, the wrapped line. The same header plus @bracket "[" "]", and the array broken after its comma. Between the bracket's sides the newline is whitespace, and the file reads whole; take the @bracket line out and the same file is refused, no rule reads '\n' here, which was the recorded answer until 2026-09-07:

; toml-wrapped.mx -- property 4: the same header as toml.mx plus one line,
; and the array wrapped onto a second line. The newline is a separator, and
; between a declared bracket and its match the lexer treats it as whitespace,
; so the file reads whole. Without the @bracket line it is refused.

@token number "[0-9]+"
@token string "\"[^\"]*\""
@token name   "[A-Za-z_][A-Za-z0-9_-]*"
@separator "\n"
@bracket "[" "]"
@syntax "[" t:name "]"                        => "section {t}"
@syntax k:name "=" v   10                     => "  {k}: {v}"
@syntax "[" [ x ]* sep "," join ", " "]"      => "list({x})"
@end
[server]
hosts = ["a",
         "b"]

$ mx docs/languages/toml-wrapped.mx
section server
  hosts: list("a", "b")

SQL. Keyword-led mixfix with a comma list and two optional clauses. A clause that was not there splices as nothing, which is what an optional group is:

; sql.mx -- keyword-led mixfix with a comma list and optional clauses, which
; is the pattern language's native shape.

@token number "[0-9]+"
@token name   "[A-Za-z_][A-Za-z0-9_]*"
@separator ";" => ";\n"
@syntax "select" [ c ]+ sep "," join ", " "from" t:name [ "where" w ] [ "order" "by" o ]
    => "scan({t}) | filter({w}) | sort({o}) | project({c})"
@syntax a "=" b   40   => "{a} == {b}"
@syntax a ">" b   40   => "{a} > {b}"
@end
select id, total from orders where total > 100 order by id;
select name from users

$ mx docs/languages/sql.mx
scan(orders) | filter(total > 100) | sort(id) | project(id, total);
scan(users) | filter() | sort() | project(name)

JSON. Two rules and three words, and no separator, so the newlines are whitespace and the body is one expression. The object's keys and values are two lists in one group, which a code template pairs and a string template cannot:

; json.mx -- two rules read it, and the body is one expression, so no
; separator is declared and a newline is whitespace. The object's keys and
; values are two lists, paired by the code template.

@token number "-?[0-9]+(\\.[0-9]+)?"
@token string "\"[^\"]*\""
@syntax "{" [ k:string ":" v ]* sep "," "}"
    => { emit "map("; for i, x in k sep ", " { emit x + " = " + at(v, i) }; emit ")" }
@syntax "[" [ v ]* sep "," join ", " "]"   => "seq({v})"
@syntax "true"   => "T"
@syntax "false"  => "F"
@syntax "null"   => "nil"
@end
{"name": "mx",
 "tags": ["c", "make"],
 "ok": true, "size": 1.5, "next": null}

$ mx docs/languages/json.mx
map("name" = "mx", "tags" = seq("c", "make"), "ok" = T, "size" = 1.5, "next" = nil)

CSS. A rule with its declarations and a class selector. The wall is not in this file: url(a.png) is a token that exists only after url(, and no class can say so:

; css.mx -- a rule, its declarations and a selector read. `url(a.png)` is
; the wall: that token exists only after `url(`, and no class here can say
; so. Two holes in one group are two lists, paired by the code template.

@token number "[0-9]+(px|em|%)?"
@token name   "[A-Za-z_-][A-Za-z0-9_-]*"
@token hex    "#[0-9a-fA-F]+"
@syntax s:name "{" [ p:name ":" v ]* sep ";" "}"   50
    => { emit "rule(" + s; for i, x in p { emit "; " + x + " = " + at(v, i) }; emit ")" }
@syntax "." c:name   => "class({c})"
@end
h1 { color: #333; margin: 0 }

$ mx docs/languages/css.mx
rule(h1; color = #333; margin = 0)

XML, element-only. A tag with attributes, children, a self-closing tag and a close all read, with the children as a stmts hole under @separator " ". What does not read is the text between the tags, xml-text.mx above:

; xml.mx -- an element-only document reads: a tag, attributes, children, a
; close. Compare xml-text.mx.

@token name   "[A-Za-z_][A-Za-z0-9_-]*"
@token string "\"[^\"]*\""
@separator "\n"
@syntax "<" n:name [ a:name "=" v:string ]* join " " ">" c:stmts "</" m:name ">"
    => "{n}[{a}={v}]({c})"
@syntax "<" n:name [ a:name "=" v:string ]* join " " "/>"
    => "{n}[{a}={v}]"
@end
<doc id="1">
  <item kind="a"/>
  <item kind="b"/>
</doc>

$ mx docs/languages/xml.mx
doc[id="1"](item[kind="a"]
item[kind="b"])

Lua. No separator is declared in the language, and property 4 forgives it: a statement that ends in ) or end ends in a word, after which no separator is wanted, and one that ends in a name has a newline after it, which is the separator here:

; lua.mx -- no separator is declared in the language, and property 4
; forgives it: a statement that ends in `)` or `end` ends in a word, and one
; that ends in a name has a newline after it, which is the separator here.

@token number "[0-9]+"
@token name   "[A-Za-z_][A-Za-z0-9_]*"
@separator "\n" => ";\n"
@syntax "local" v:name "=" e                    => "int {v} = {e}"
@syntax v:name "=" e   10                       => "{v} = {e}"
@syntax a "+" b   60                            => "{a} + {b}"
@syntax a "<" b   40                            => "{a} < {b}"
@syntax "if" c "then" b:stmts "end"             => "if ({c}) {{ {b}; }}"
@syntax "while" c "do" b:stmts "end"            => "while ({c}) {{ {b}; }}"
@syntax "print" "(" x ")"                       => "printf(\"%d\\n\", {x})"
@end
local x = 1
while x < 3 do
  x = x + 1
  if x < 3 then print(x) end
end
print(x)

$ mx docs/languages/lua.mx
int x = 1;
while (x < 3) { x = x + 1;
if (x < 3) { printf("%d\n", x); }; };
printf("%d\n", x)