YINI Cheat Sheet

Based on the official YINI Specification (v1.0 Release Candidate 6)

A quick reference for writing clean, readable YINI configuration files.

YINI makes data files (such as configuration files and application settings) easy for humans to read and predictable for machines to process — like INI, but with real structure, lists (arrays), objects, and comments.

More structured than INI, less noisy than JSON, and less fragile than YAML.

🧱 Basic Syntax

📝 Naming Rules

• Simple section names and keys should use normal identifier-like names.
• Use backticks for spaces, punctuation, special characters, or reserved-looking names:

^ `My App`
`api-key` = "abc123"
`user.name` = "Alex"

💡 Style Convention (Optional)

• Section names typically start with a capital letter, like: Title.
• Keys typically start with a lowercase letter, like: key.

This is a readability convention — not a requirement.

🔤 String Types

YINI strings are quoted and are raw by default.

Use normal raw strings for most values. Use C"..." or C"""...""" only when you need escape sequences.

🧩 Inline Objects & Nested Data

Objects are also called maps or dictionaries in many languages.

Simple object

db = { host: "localhost", port: 5432 }

Nested objects

service = {
    http: { port: 8080, secure: true },
    limits: { rpm: 1000 }
}

🧭 Important Rules

• Indentation is cosmetic — structure is defined by section markers (^, ^^, ^^^, etc.).

• Repeated section markers are supported up to level 9. For deeper nesting, use numeric shorthand such as ^10 DeepSection.

• Strings must be quoted using '...' or "...".

• Strings are raw by default. Use C"..." or c'...' only when you need escape sequences like \n or \t.

• key = value assigns a single value.

• Lists are assigned with = and square brackets, for example items = ["one", "two"].

• Trailing commas are allowed in lists and objects (lenient mode).

• Duplicate keys are disallowed by default.

• # starts a comment outside string literals.

• _ may be used as a visual separator in number literals and repeated section markers. It improves readability and does not change the value or section depth.

  maxUploadSize = 10_000_000

  Meaning: same as 10000000, but easier to read.

  ^^^_^^^_^^^ DeepSettings

  Meaning: same section depth (9 in this case) as ^^^^^^^^^ DeepSettings; the _ separators are only visual and do not count as section markers.

🔢 Number Formats

YINI supports multiple numeric formats:

All numeric forms are parsed as real numbers — no quotes required.

🧪 Example 1 — Minimal Real-World

^ App
name = "Nebula"
version = "2.3.1"

^^ Network
ports = [80, 443]
ssl = true   // boolean (case-insensitive)

^^ `Rate Limits`
requests = { perMinute: 1200, burst: 60 }
timeout = null

🧪 Example 2 — Practical Config with Comments

# Optional YINI marker
@yini

^ Service
name = 'Aurora'                 # Single quotes
message = C"Server started\nReady."   # C-string with newline escape
path = 'E:\Program Files\App'   # Backslashes are raw (no escaping needed)
enabled = Off                   # Boolean (case-insensitive)
retries = 3

    ^^ Database
    host = 'localhost'
    port = 5432
    color = 0x336699            # Hex number literal

    ; This is a full-line comment (for humans)
    --password = 'secret'       # Disabled line (ignored by parser)

        ^^^ Limits
        maxUsers = 1000
        timeout =               # Blank value → null (lenient mode)

💡 Strings:
Regular strings are raw by default.
Use C"..." or c'...' only when escape sequences are needed.

💡 Note:
Lines prefixed with -- are disabled configuration lines.
They behave like comments (the parser ignores them), but are intended to temporarily disable real configuration — not to serve as documentation.

In editors, they are typically highlighted differently from normal comments to indicate “disabled code” rather than explanatory text.

Next Steps

• ➡️ YINI Code Examples
  Explore real-world configurations.
• ➡️ Get YINI Tools
  CLI, parser libraries, and editor tools.