11. Canonical formatting
Readable Object Notation

A packed list stays on one line if it fits the 100-column target. When it does not fit, the formatter balances its items across rows as close to a square as the width allows. It computes the ceiling of the square root of the item count as the target column count, then distributes items as evenly as possible over the resulting rows, with longer rows first. If a row would exceed 100 columns, it wraps early. A single item may still exceed the target.

String spelling follows the canonical string-formatting rules above. Comments stay attached to their members as those members are sorted. Non-hanging container contents use two additional spaces of indentation.

A canonical RON document can be hashed directly. Hash the complete UTF-8 encoding of its canonical output. Canonical output uses LF (0a) for internal line breaks, has no byte-order mark, and appends no terminal line feed. Hashes are over bytes, not the JSON rendering or the original input.

{name Ada age 36 active true}

<active>
age 36
name Ada

{
  "name": "Ada",
  "age": 36,
  "active": true
}

For the canonical RON shown above, the bytes are <active>\nage 36\nname Ada, with no terminal newline. The following digests cover that entire canonical document. Both are 256-bit digests written as lowercase hexadecimal:

BLAKE3 is a cryptographic hash designed for high throughput; SHA-256 is widely supported. RON does not select a mandatory hash algorithm. Store the algorithm name with a digest so the two cannot be confused.

Different source layouts that produce identical canonical bytes produce the same hash. RON preserves comments, so changing a comment changes the bytes and hash. Integers and floats remain distinct: 1 and 1.0 have different canonical bytes. Unicode strings are not normalized, so different code point sequences remain different even if they look alike. Key names sort by Unicode scalar value (equivalently, lexicographic order of their valid UTF-8 encodings).

For repeatable hashes across implementations, use the same RON specification version and the same hash algorithm. A hash is a compact identifier for bytes; compare canonical bytes too when exact equality must be established.

Canonical formatting joins closing }, ], and > delimiters to the last content line when doing so preserves the value. Consecutive closers stack on that line; indentation does not replace any delimiter.

; Closers may follow the last item or member on its line, as a Lisp
; stacks its parens; a comment there belongs to the last closer.
query {
  find [?name]
  where [
    [?e name ?name]
    [> ?sal 85]]} ; the query
tags [
  database
  graph]
spaced {
  a [
    x
    y ] }
member {
  summary One person}
quoted {
  description """The person"""}
commented [
  graph ; the item keeps its closer apart
]
text {
  body """
    hi
  """
}

; Closers may follow the last item or member on its line, as a Lisp
; stacks its parens; a comment there belongs to the last closer.
commented [
  graph ; the item keeps its closer apart
]
member {summary "One person"}
query {find [?name]
       where [[?e name ?name] [> ?sal 85]]} ; the query
quoted {description "The person"}
spaced {a [x y]}
tags [database graph]
text {body hi}

{
  "$comment": "Closers may follow the last item or member on its line, as a Lisp\nstacks its parens; a comment there belongs to the last closer.\nquery: the query\ncommented[0]: the item keeps its closer apart",
  "query": {
    "find": [
      "?name"
    ],
    "where": [
      [
        "?e",
        "name",
        "?name"
      ],
      [
        ">",
        "?sal",
        85
      ]
    ]
  },
  "tags": [
    "database",
    "graph"
  ],
  "spaced": {
    "a": [
      "x",
      "y"
    ]
  },
  "member": {
    "summary": "One person"
  },
  "quoted": {
    "description": "The person"
  },
  "commented": [
    "graph"
  ],
  "text": {
    "body": "hi"
  }
}

Boolean members follow the same rule, including tags nested inside objects:

person {
  <active !admin>
  name Ada
}
flags {<readable !writable>}

flags <readable !writable>
person {<active !admin>
        name Ada}

{
  "person": {
    "active": true,
    "admin": false,
    "name": "Ada"
  },
  "flags": {
    "readable": true,
    "writable": false
  }
}

A trailing comment ends its line. The closing delimiter stays on the next line so it cannot become part of the comment:

outer {
  name Ada ; Keep this comment
}

outer {name Ada ; Keep this comment
      }

{
  "outer": {
    "$comment": "name: Keep this comment",
    "name": "Ada"
  }
}

A multiline string’s closing fence also ends its line. Container closers follow on the next line:

outer {
  text """
    hello
  """
}

outer {text hello}

{
  "outer": {
    "text": "hello"
  }
}