Toon

TOON logo

TOON means Token-Oriented Object Notation.

It is a compact, human-readable notation for structured data. Its general goal is to encode JSON-like data with fewer tokens while keeping enough structure for humans and language models to inspect it reliably.

TOON is especially useful when data contains repeated records with the same fields. Instead of repeating every object key like JSON, it can declare the array length and fields once, then list rows in a compact table-like form.

Format concern	TOON approach
Nested objects	YAML-like indentation.
Uniform arrays	CSV-like rows with one shared field header.
Structure	Explicit array lengths and field lists.
Readability	Plain text, compact rows, minimal punctuation.
LLM prompts	Lower token overhead than verbose JSON for suitable data shapes.

General Shape

TOON keeps scalar values readable and uses table headers for arrays of uniform objects.

context:
  task: Runtime primitive catalog
  target: wasm32

primitives[3]{id,c_name,kind}:
input.read_object,input_read_object,host
response.status,response_status,host
string.trim,sx_trim,pure

The header primitives[3]{id,c_name,kind} declares 3 rows · 3 shared fields. Structure stays explicit; keys appear once.

When It Fits

Uniform records

Primitive lists · tool schemas · route inventories · artifact manifests · benchmark rows · small structured LLM datasets.

Shared field headers make these catalogs compact.

Keep another format when clearer

Deeply nested or irregular data, or data already smaller as plain JSON or CSV.

JSON can remain the programmatic interchange format; TOON provides a shorter presentation and prompt view.

Toon In sigMAX

sigMAX uses Toon as a compact catalog notation in the runtime repository.

The canonical catalog is runtime/functions.toon, currently declaring sigmax.primitives.catalog/v0.3. It describes C and MoonBit targets, WASM imports, capabilities, signatures, pseudo-code aliases, limits and generation rules. The bindings live in runtime/C/sigma.h and runtime/moonbit.

sigMAX Catalog Content

runtime/functions.toon combines scalar metadata, rule lists and compact typed tables.

Catalog fields: metadata, ABI, primitives, rules and patterns

Section	Purpose
`schema_version`	Identifies the catalog schema.
`runtime`	Records the Rust host, WASM target and C subset / MoonBit source targets.
`canonical_abi`	Records language-neutral value, ownership and error conventions.
`primitive_metadata[...]`	Records target support, stability, effects, ownership and errors.
`global_rules`	Lists safety rules the generator must preserve.
`forbidden_call_patterns`	Lists prohibited calls; validation uses parsed syntax or IR rather than substring checks.
`categories[...]`	Defines primitive families such as input, response, storage, HTTP and JSON.
`primitives[...]`	Maps IDs to names, imports, capabilities, signatures and `@...` aliases.
`pseudo_words[...]`	Describes compact DSL instruction words and lowering rules.
`limits[...]`	Records bounded runtime defaults.
`capability_rules`	Explains when host primitives are allowed or denied.
`llm_generation_rules`	Constrains generated C subset code.
`patterns[...]`	Provides reusable generation patterns.

Why sigMAX Uses Toon

The primitive catalog is dense. YAML would be readable but verbose for repeated rows, while raw CSV would lose hierarchy and rule sections. Toon keeps the catalog compact without turning it into executable code.

Need	Toon contribution
Compact rows	Table blocks keep many primitives readable.
Typed columns	Headers document each column once.
Mixed content	Rules, limits and tables can live in one file.
Generation input	The catalog is deterministic enough to feed prompts or code generation.
Reviewability	Humans can audit primitive names, imports and capabilities in one place.

Illustrative Catalog Projection

This reduced view demonstrates the notation. In the canonical catalog, aliases are stored in the pseudo column of primitives[...]; the projection below is not a replacement catalog schema.

categories[3]{id,kind,description}:
input,host,Read route parameters or typed request bodies
response,host,Set status and emit structured ObjectIR
string,pure,Bounded string helpers

primitive_aliases[3]{pseudo,c_name}:
@body,input_read_object
@stat,response_status
@blank,sx_is_blank

In sigMAX, this means @body is not an invented keyword. It has a catalog entry, a concrete C lowering target and a runtime boundary.

sigMAX Design Rule

Toon should describe generation vocabulary and constraints, not hide behavior.

If a generated handler uses a pseudo keyword, the Toon catalog should make it possible to answer:

which C helper or host import it lowers to;
whether it is pure or host-controlled;
which capability is required;
which signature and limits apply;
whether the binary contract must list a WASM import.

That keeps generation compact while preserving the contract-first audit trail. A catalog entry does not prove executor compatibility: Core uses container execution on the Host/Config machine, while Pro uses COS2000 in a KubeVirt VM. Imports and data representations must be validated for the chosen executor.

Toon

Toon

General Shape

When It Fits

Toon In sigMAX

sigMAX Catalog Content

Why sigMAX Uses Toon

Illustrative Catalog Projection

sigMAX Design Rule

References