yamlscript

name	yamlscript
description	Write idiomatic YAMLScript code. Use when asked to write, convert, or review YAMLScript (.ys files). Converts Clojure to idiomatic YAMLScript using confirmed style rules and tested examples.

YAMLScript Skill

Setup

Ensure ys version 0.2.32 is available for testing:

[[ -x /tmp/ys-skill/bin/ys-0.2.32 ]] ||
  curl -s https://yamlscript.org/install | VERSION=0.2.32 PREFIX=/tmp/ys-skill bash
YS=/tmp/ys-skill/bin/ys

Optionally clone the source for looking up stdlib functions, DWIM support, and docs:

[[ -d /tmp/ys-skill/yamlscript ]] ||
  git clone --depth 1 https://github.com/yaml/yamlscript \
    /tmp/ys-skill/yamlscript
# Key files:
#   core/src/ys/std.clj   — YS standard library
#   core/src/ys/dwim.clj  — functions with auto arg-placement
#   doc/                  — language documentation

Workflow

1. Write correct Clojure first — Clojure is unambiguous; get the logic right before worrying about YS syntax

2. Convert to YAMLScript — apply the rules below

3. Test every attempt before presenting it:

   # Single-line expressions
   $YS -pe 'expr'
   # Multi-line programs
   $YS -c - <<<'!ys-0 ...'
   

4. Iterate until the output is correct and idiomatic

5. Lint the source with the ys-lint.ys script that ships next to this SKILL.md (same skill directory). Run it against every .ys file you wrote or edited:

   /path/to/skill/ys-lint.ys FILE...
   

   ys-lint.ys flags possible surface-form mistakes the compiler can't see because they vanish at the AST stage: .nth(N) vs .N, .nth(var) vs .$var, x + 1 vs .++, x - 1 vs .--, .first() / .last() vs .0 / .$ (or :first / :last), vector(...) and inline V+(...) vs +[...], inline M+(...) vs +{...}, avoidable apply calls vs direct splats (f(xs*) / f: xs*), str(bareVar) vs bareVar:S, quot(a b) and a.quot(b) vs a // b, rem(a b) vs a % b, parenthesized simple integer-looking divisions such as (n / d) vs (n // d), :zero? vs .! when falsey-zero semantics are OK, or( / and( calls vs || / &&, any KW (cond): test-expression paren-wrap (for if, if-not, when, when-not, while), any KW [...]: bracketed binding form for the reliably-strippable keywords (binding, if-let/if-lets/if-some, let, loop, when-first/when-let/when-lets/when-some, with-open) and for the iteration keywords (each, for, doseq, dotimes) when the binding starts with a named var (not a _-var or destructure pattern), then: nil / else: nil vs when / when-not, direct then: false under if as a candidate for reversed when, a zero-arg method x.foo() vs the colon chain x:foo, a =>: whose value is a call / colon-chain / dot-chain / spaced binary op vs a pair form (f: args / x: .m(a) / a OP: b), a direct =>: child under an if block vs then: / else:, say: '' vs bare say:, x.join(' ') vs the colon chain x:joins, slurp / spit vs read / write, plain-YAML structural checks such as scalar then: / else: branches that can be positional if branches, a wide recur: / loop arg list that should be comma-separated, and lines over 79 cols.

   Most linter rules match source text with regex; a few strip the top !ys-0 tag, load the file as plain YAML, and inspect the YAML shape. Every hit is still a candidate, not a verdict. False positives are expected: a long line may be a literal task string the program can't shorten; an x - 1 inside a generated string isn't a .-- candidate; an identifier that happens to look like a pattern may not be one. Inspect every reported line, fix the real mistakes, and explicitly justify each hit you treat as a false positive. This step is required: the working program isn't done until you have walked every lint hit and either fixed it or accepted it with reason.

Program Tag

• Always use !ys-0 — the short idiomatic form
• !yamlscript/v0 and !yamlscript/v0/ are legacy — do not use
• !ys-0 = code mode; !ys-0: = data mode

YS vs Clojure Standard Library

Prefer YS stdlib functions (ys.std) over their Clojure equivalents — they are more powerful and polymorphic (e.g. reverse works on strings, replace defaults the replacement to "", rng works on chars). If performance is a concern, fall back to the specific Clojure function for that case.

Most Math/* functions are exposed in ys.std (sqrt, sqr, floor, abs, pow, etc.). Drop the Math/ prefix when a YS builtin exists; it's more idiomatic.

Common Mistakes

Patterns Claude gets wrong most often. Scan these before writing any YS.

Use if for two-branch conditionals — cond only for 3+ branches

cond is only appropriate when there are three or more mutually exclusive branches. Any time you have a single predicate plus an else: (one real branch and one fallback), use if instead. This is the single most common conditional mistake.

• cond: x == 0: a / else: b → if x == 0: \n then: a \n else: b
• cond: pred: x / else: recur(...) → if pred: \n then: x \n else: recur(...)

if can drop the then: and else: keys when both branches are pair-form children (mapping entries), because YS reads the two children positionally regardless of their keys. The keys can even collide:

if (n % d) == 0:
  recur: quot(n d) d cnt.++
  recur: n d.++ cnt

This also lets the then-branch be a nested if X: pair while the else-branch is an explicit else::

if n >= 2:
  if (n % d) == 0:
    recur: ...
    recur: ...
  else: cnt

Bare-scalar branches (plain identifiers, calls, expressions) can also drop then: / else: when both branches are simple direct scalar values with no whitespace and neither branch starts with YAML syntax characters such as quotes, brackets, braces, block-scalar markers, or tags:

if prime?(candidate):
  count.++
  count

Prefer this over:

if prime?(candidate):
  then: count.++
  else: count

The linter flags {if ...: {then: scalar, else: scalar}} shapes by loading the file as plain YAML and checking the branch values, but only when both scalar branch source values contain no whitespace. This rule deliberately skips quoted strings and other YAML-special starts. This is not the same as using =>: under if, which is never correct.

Bare-scalar branches are still fragile when mixed with mapping entries: mixing a bare scalar with an else: mapping entry is invalid YAML. When in doubt, keep then: and else: explicit unless both branches are pair-form children or both are simple direct scalar branch values with no whitespace and no YAML-special start.

When both branches are bare scalars, a trailing + on the if line folds the next two indented lines into one plain scalar that YS reads as the remaining positional args of if:

if n == 1: +
  '1'
  factors(n).join(' x ')

Compiles to (if (= n 1) "1" (str/join " x " (factors n))). Use this when both branches are short bare expressions and the symmetry reads better than then:/else: keys.

Inner conditionals nested inside a cond clause are usually two-branch and should be if. Before writing cond:, count the clauses: if it's two (one predicate + else:), rewrite as if. Three or more clauses (excluding else:) keeps cond.

Scan every cond: in the file before finishing — if it has only one non-else: clause, it's wrong.

=>: only when no pair form works

A YAML mapping context — defn body, do: block, conditional branch block, loop body, etc. — requires every line to be a key: value pair. =>: is the fallback key when the expression genuinely cannot be written as a pair.

Use =>: for atomic values (no other pair form exists):

• bare identifiers: =>: x, =>: result
• bare numeric/literal atoms: =>: 42, =>: nil, =>: true, =>: :foo
• bare interpolated strings: =>: "$s$check"
• bare data-collection literals: =>: +[1 2 3], =>: +{a: 1}

Never use =>: as a direct branch key of an if construct. Even when the branch result is an atom that would normally allow =>:, an if branch already has semantic keys. Use then: or else: instead:

if done?:
  then: result
  else:
    recur: next

not:

if done?:
  =>: result
  else:
    recur: next

Restructure compound expressions into a pair:

1. Function call → fn-call pair name: args
   • =>: f(a b) → f: a b
   • =>: vec(out) → vec: out
   • =>: foo() → foo:
   • =>: recur(i.++ b nx) → recur: i.++ b nx
   • =>: V+(re im) → V+: re im
2. Dot/property or method chain → chain-pair receiver: .member
   • =>: x.y → x: .y
   • =>: a.b(c).d(e) → a: .b(c).d(e)
   • =>: row.assoc(w best) → row: .assoc(w best)
   • =>: meta.from.split('/wiki/').$ → meta.from: .split('/wiki/').$
3. Binary operator → op-pair lhs OP: rhs
   • =>: a + b → a +: b
   • =>: n == psum → n ==: psum
   • =>: is-thu || is-wed-leap → is-thu ||: is-wed-leap
4. cond default arm: use else: not =>:

Drop single-use indirection: a result =: expr whose only use is a trailing =>: result folds into a single trailing pair:

• result =: r:sqr == n; =>: result → r:sqr ==: n
• result =: row.conj(s); =>: result → row: .conj(s)

Colon-chains must convert to dot-chains in chain-pair position — chain-pair only supports a leading .:

• =>: out:V → vec: out
• =>: stack:pop:pop.conj(x) → stack: .pop().pop().conj(x)

Op-pair / pair-form quirks:

• %: with a scalar value is the pair form of the remainder operator: a %: b compiles to (rem a b). With a mapping value, trailing % is the legacy generic form-map marker instead.
• An operator-pair scalar value must contain exactly one form. A compound expression such as a %: b - c is one form, but a %: b c is invalid. Mapping values retain their mapping and form-map semantics.
• A pair value cannot begin with a quoted string followed by more args. format: '%+.4f' x y fails to parse. Workarounds:
  • Promote the string into the key: format '%+.4f': x y
  • Force it into the value with +: format: +'%+.4f' x y

Never write x + 1 or x - 1 — use .++ / .--

Increment and decrement by 1 are common enough to have their own postfix operators. Use them anywhere — assignment values, argument positions, return values, loop bodies, string interpolation:

• v + 1 → v.++
• v - 1 → v.--
• (3 * v) + 1 → (3 * v).++
• recur: i + 1 → recur: i.++

.++ and .-- compile to inc+ / dec+ (polymorphic). This is the single most-forgotten rule — scan every + 1 and - 1 before finishing.

Exception: do not rewrite f + 1 when f is a function and the expression is a partial application. For example, (rotate + 1) means "a function that calls rotate with 1 as its first argument"; it is not numeric increment and must not become rotate.++.

Never write .nth(N) or .nth(bareVar) — use .N / .$var

Index access has terse dot-forms that should be preferred over the explicit .nth(...) call:

• v.nth(0) → v.0 (literal integer index)
• v.nth(12) → v.12
• s.nth(0) → s.0 (works on strings too)
• parts.nth(2) → parts.2
• v.nth(i) → v.$i (bare variable index)
• v.nth(idx) → v.$idx
• m.nth(ip) → m.$ip

.nth(expr) is only correct when the index is a computed expression — e.g. v.nth(i.--), v.nth((row * 4) + c), v.nth(i + g). The .$var form takes a single bare variable; it does not accept compound expressions.

Scan every .nth( in the file before finishing — if the argument is a literal integer or a bare variable, rewrite to the dot/dollar form.

.first() / .last() — use .0 / .$ or :first / :last

The call form x.first() and x.last() is verbose. Two terser alternatives, each with its own niche:

• .0 / .$ — positional access. Use when the value is a vector or pair and you're thinking "first/last element by index":
  • pair.first() → pair.0
  • tuple.last() → tuple.$
  • sorted.first() → sorted.0
• :first / :last — colon-chain. Use when the value is a sequence and you want the seq operations' "head/tail" framing:
  • tri.last() → tri:last
  • lines.first() → lines:first

Either reads better than the call form. Pick by whether the data is indexable (.0/.$) or seq-like (:first/:last); both compile to the same thing for vectors, so when in doubt use the dot form.

Never write vector(...) literals — use vector syntax

vector(a b c) (the fn call) and vector literal syntax build the same thing. Always prefer vector syntax — it reads as a literal, not a function call.

Use +[...] only when the vector literal is the entire YAML value plain scalar and therefore needs the leading + escape:

• vector(a b c d) → +[a b c d]
• vector(nt ny) → +[nt ny]
• vector() → +[]

Inside YeS expressions, function arguments, lambdas, method calls, or any other expression context where [ is not the first character of the YAML value, use bare [...] with no +:

• digits.map(\(vector(_ s))) → digits.map(\([_ s]))
• rest.conj(vector(v ns)) → rest.conj([v ns])

Never write \(+[...]), foo(+[...]), or obj.method(+[...]). There + is not an escape; it is parsed as addition/concatenation.

Use vec(coll) only when you're converting an existing collection, not when listing elements.

Prefer +[] / +{} for collection literals

Use +[...] and +{...} for collection literals when the literal starts the YAML value. They read as literals and should be the default for short vectors and maps in value position, including maps with computed values:

pair =: +[name score]
node =: +{:char ch :freq freq}

If the literal is inside a YeS expression, drop the + because the literal no longer starts the YAML value:

items.map(\([name score]))
nodes.conj({:char ch :freq freq})

Use V+ and M+ mainly when the collection constructor is the pair key, especially for block form or when the call layout is clearer as a YAML pair:

M+: :a 1, :b 2

V+:
  item-a
  item-b
  item-c

Avoid inline V+(...) / M+(...) when a +[...] / +{...} literal is equally clear.

Avoid defensive :V

Do not add :V just because a value is lazy or because the next form will iterate it. Prefer leaving sequence-producing calls as sequences, then run the program without materializing first.

Add :V only when the program needs vector behavior:

• indexed access with .N / .$i
• vector-style conj order
• repeated traversal where laziness would be surprising
• output must visibly print as a vector
• a later operation specifically requires an indexed collection

When unsure, remove :V and run the program. Keep it only if the program fails or the output semantics change.

Prefer direct splat calls over apply

YS 0.2.32 can splat collection-producing expressions directly into a call. When the collection is already a value or fits naturally in a scalar expression, call the target function and append * to the collection instead of wrapping the call in apply:

• apply(max xs) → max(xs*)
• apply max: xs → max: xs*
• apply(min-key score xs) → min-key(score xs*)
• apply(max 0 map(count lines)) → max(0 map(count lines)*)
• apply(concat groups) → concat(groups*)
• apply f: args → f: args*

The splatted argument can be a variable (xs*), a parenthesized expression (([f] + args)*), a call result (make-args()*), a dot-chain (rows.map(count)*), or a colon-chain (freqs:vals*). Regular arguments may appear before it, and calls may contain multiple splats.

For operator functions, use a named callable such as add(xs*), mul(xs*), or le(xs*); a parenthesized operator head such as (+ xs*) also works.

Use :join / join: when the operation is conceptually joining strings: apply(str pieces) can become pieces:join. Use str(pieces*) when the variadic str call itself is the clearer expression.

Keep apply when the collection is naturally produced by an indented block and forcing it into a scalar expression would make the code less clear:

apply max-key last:
  map _ xs:
    fn(x): score(x)

Prefer :S colon-chain over str(bareVar)

Single-argument str(x) where x is a bare identifier has a terser colon-chain form x:S. Use that:

• str(c) → c:S
• str(n) → n:S

:S reads as "convert to String" — that's exactly what the call is doing. Use it whenever the intent is stringification.

Don't rewrite str(bareVar) as "$bareVar". Interpolation is for composing a string from parts, not for stringification — even when the result happens to look the same. And the two are not always equivalent: at the interpolation boundary the value's original type can leak through (a Character can come back as a Character), whereas str(x) and x:S always produce a real String. The difference shows up in places where the result is used as a map key, a regex operand, or an in? test — Soundex's code-map lookup is a real example where "$c" misses entries that c:S finds.

str(...) with multiple args (e.g. str(a b c) for concatenation) is unrelated — keep it. The rule is only about the single-bare-var case.

Prefer .! over :zero? when falsey-zero semantics are OK

YS falsey semantics make numeric 0 false, so .! is usually the terser way to test "zero result" in numeric code. Prefer it for counts, remainders, and loop totals when the value is known to be numeric:

• (i % 5).! over (i % 5):zero?
• count.! over count == 0 or count:zero?
• total.! over zero?(total)

Use :zero? / zero?(...) only when you specifically need the stricter predicate and must distinguish numeric zero from nil, false, empty strings, or empty collections.

Use conditional assignment for "if true update, else keep same value"

YS 0.2.32 supports conditional assignment targets. When an assignment would set a target to a new value only when a condition is true, and otherwise keep the same target value, put the condition in the target:

foo :if pred =: bar

This means "if pred, assign bar to foo; otherwise keep foo". Prefer it over the verbose self-fallback shape:

foo =:
  if pred:
    then: bar
    else: foo

The same syntax works with update assignments:

count :if prime?(candidate) +=: 1

over:

count =:
  if prime?(candidate):
    then: count.++
    else: count

It also works with destructuring and functional/modified assignment operators (+=:, *=:, ||=:, .=: etc.):

a b c :if (x == y) =: d e f
total :if include? +=: n
data :if found .=: assoc(k v)

The condition after :if must be a single form. Parenthesize compound conditions: a b :if (x == y) =: c d, not a b :if x == y =: c d.

else: not do: for the else branch of if

When the then-branch is a single form and the else-branch is multiple forms, introduce the else block with else:, not do:. do: compiles but is not idiomatic.

when/when-not for one-armed conditionals returning nil

If a branch of if or cond returns nil, the conditional is really one-armed — use when (or when-not) instead. when returns nil when the test is false, so the explicit nil branch is dead weight. A cond with one real arm and a nil fallback is the loudest version of this mistake.

• cond: x.!: nil / else: real → when x: real
• cond: m: i / else: nil → when m: i
• if cond: form / else: nil → when cond: form
• when X.! → when-not X

When an if has then: false, consider reversing the condition and using when for the else branch. when returns nil when its test is false, and nil often works anywhere false was only used as "no result":

if letters.# < 2:
  then: false
  else:
    every?: ...

can become:

when letters.# >= 2:
  every?: ...

Only make this rewrite when nil is acceptable in place of false. Keep the explicit if when callers require a strict Boolean false.

declare is not needed in YAMLScript

YS resolves defn references across the whole file, so mutual recursion works regardless of definition order. Don't reach for declare: name — it's a Clojure habit and adds noise:

# correct — F is defined first and references M defined later
defn F(n):
  if n.!: 1 (n - M(F(n.--)))

defn M(n):
  if n.!: 0 (n - F(M(n.--)))

No reserved symbols in YS or Clojure

Any symbol can be used as a local binding. Names that shadow stdlib functions (next, count, key, name, val, type, class, first, last, rest, map, line, done, etc.) are fine. Don't invent abbreviations like nxt, cnt, k, or done? just to avoid the stdlib name.

# correct
next =: next-board(b)
when next: recur(next)

# wrong reaching for `nxt` to avoid shadowing `next`
nxt =: next-board(b)
when nxt: recur(nxt)

Pick the clearest name from the domain. The only reason to avoid a particular symbol in a scope is if you need to use the original value in that same scope.

Style Defaults

The choices below have no single right answer in YAMLScript. The skill ships with the defaults listed here, but they are overridable from a project's CLAUDE.md. If a project's CLAUDE.md contradicts a default, follow the project.

These are stylistic only — anything in Common Mistakes, Key Rules, or Anti-Patterns is not negotiable.

Prefer subject-first chains over nested calls

When a function has an obvious "subject" argument (the thing being extended, transformed, queried, or tested), prefer the subject-first chain form over a nested function call. Less parenthesizing is usually better, and subject:op / subject:op1:op2 reads left-to-right:

• n:random-brackets over random-brackets(n)
• s:balanced? over balanced?(s)
• s:seq over seq(s)
• brackets:seq:shuffle over shuffle(seq(brackets))
• m.assoc(:k v) over assoc(m :k v) when args are needed
• xs.conj(x) over conj(xs x) when args are needed
• s.split('/') over split(s '/') when args are needed

Use colon chains for zero-argument calls and subject-first unary calls: b:a is preferred over a(b), and c:b:a is preferred over a(b(c)), when the chained order is the natural data flow.

Use the bare-function form when arguments are co-equal (e.g. merge(a b c), concat(xs ys zs)) or when there is no natural receiver.

To override: in CLAUDE.md, write "prefer bare-function form (assoc(m k v)) over receiver-first chains".

Vectors of short strings

For a static vector of short word-like strings, prefer qw(a b c) over =:: ['a', 'b', 'c']:

• colors =: qw(red green blue) over colors =:: ['red', 'green', 'blue']

qw produces a vector of strings. Use the data-mode literal when the elements contain spaces or non-word characters.

Default argument values

For a defn arg with a long default value, prefer setting it in the body with ||=: over a long signature line:

defn main(text=nil):
  text ||=: 'The quick brown fox jumps over the lazy dog'

over

defn main(text='The quick brown fox jumps over the lazy dog'):

Short defaults (numbers, short strings, keywords) belong in the signature: defn main(n=10):.

Block form vs chain for multi-arg calls

For a call with three or more substantial args, prefer block form with one arg per line over a single-line chain:

concat:
  quicksort(less)
  vector(p)
  quicksort(more)

over

concat: quicksort(less) vector(p) quicksort(more)

Two args fit fine on one line.

Key Rules

Formatting

• Lines must not exceed 79 columns. This is a hard limit, not a suggestion. Target 20/40/60 columns as the natural "square" sizes for most lines. YAML/YS gives you many ways to split:
  • Block form: replace a chain with an indented block
  • Intermediate variables: assign a sub-expression to a name
  • Plain scalar folding: a plain (unquoted) YAML scalar folds at any whitespace — break before a binary operator and indent the continuation:

    user =: ENV.RC_USER ||
      die('set RC_USER (botpassword username)')
    

  • Double-quoted line fold: a "..." string can be split at any space — YAML folds the newline (and the continuation's leading whitespace) into a single space. Indent the continuation to read cleanly:

    say: "map my-add over pairs:
          $(map(my-add [1 2 3] [10 20 30]):joins)"
    

  • Double-quoted backslash continuation: a "..." string can be split with \ at end of line, even when there's no whitespace to fold at. Useful for long URLs, identifiers, or any unbroken token:

    url =: "https://en.wikipedia.org/w/api.php?action=query\
            &titles=Rosetta_Code&format=json"
    

  • Block scalars (|, >): for multi-line literal text
• End the file with exactly one newline. No trailing blank line. The last byte should be one \n after the last code line, not two.

Strings

• Single quotes unless interpolation or escapes needed
• "Hello, $name!" not str('Hello, ' name '!')
• "Result: $(x * y)" for expression interpolation
• "Now: $now()" for a bare function or method call. The shortened $ident(args) form works for plain identifiers (letters, digits, underscore, hyphen) and static calls like "$System/currentTimeMillis()". Prefer it over $(ident(args)) when the call is a single function or method on a bare name.
• Interpolation stops parsing the identifier at ? or !, so predicate names break the shortened form: write "$(all-equal?(xs))", not "$all-equal?(xs)" (which interpolates only $all-equal and leaves ?(xs) as literal text). Reach for $(...) for operators, chains, anything beyond one call, or any identifier containing ? or !.
• say: | with a multi-line block — all lines interpolated and printed
• :: (double colon) is sugar for ! (mode-toggle tag). a:: b = a: ! b — toggles between code and data mode:
  • In code mode (default !ys-0), :: switches value to data
  • In data mode, :: switches value back to code
  • say:: hello — data mode: literal string "hello", not variable lookup (quoted 'hello' is already literal either way)
  • say:: | — data mode: literal block scalar (no interpolation)
  • json/dump:: with indented YAML — build data structures natively instead of json/dump: +{...} with escaped maps
  • http/post url:: — pass YAML maps as options
  • Inside a :: data block, key:: expr toggles back to code: model:: model = YAML key model with the value of variable model
  • content:: | with $var — block scalar with interpolation
  • only works on mapping pair values (key-value syntax). For sequence entries, use the explicit tag: to evaluate as code within data mode

File I/O

• Never use slurp / spit — these are the Clojure names. YS spells them read and write, and those are the only idiomatic forms:
  • read(file) — read a whole file to a string (was slurp). Colon chain: file:read, e.g. FILE:read:lines.
  • write(file content) — write a string to a file (was spit).
• FILE is bound to the running program's own source path, handy for a program that reads data embedded in itself.

Comments

• # ... — standard YAML comment to end of line. Use it between structures, after values, and at file top/bottom.
• A # comment terminates the surrounding YAML scalar, so it cannot appear inside a multi-line plain-scalar expression such as a dot-chain spread across lines.
• \"..." — YS expression-level comment. Opens with \", closes at the next ". Use it to annotate steps inside a multi-line expression where # would break the scalar:

  defn scramble(s):
    s          \"input string"
      .lc()    \"lowercase"
      .split() \"split into chars"
      .shuffle()
      .join()
      .uc1()   \"capitalize first char"
  

• \"..." constraints:
  • The body cannot contain " (no escape mechanism).
  • The body is still lexed by YAML, so YAML-special sequences must be escaped the same way they are in any plain scalar: :\ for : (colon-space), \# for # (space-hash). See Strings.
  • Not usable inside YAML string literals ("...", '...') or regex literals /.../.
  • Not usable as a standalone YAML block element — only inside an in-progress multi-line expression.

Function Definitions

• defn name(args): form with parens
• Default args over multi-arity: defn greet(name='World'):
• For multi-line default text, use a top-level block scalar variable:

  dflt =: |-
    line one
    line two
  defn main(text=dflt):
  

  Avoids the YAML plain scalar restriction that forbids : inside default values written as \n-escaped double-quoted strings
• defn- for private helpers
• Destructuring in parameter lists: defn score([a b]): binds a and b to elements of a pair argument — saves an intermediate a b =: pair line. Works for both defn and fn.
• main with default args for CLI programs. Defaults should be values a user could actually type on the command line — strings and numbers, not vectors or maps. If main needs a collection, default a string and parse it in the body (see ARGV/ARGS).
• main arg-list shapes:
  • main(name) — exactly one named arg (auto-converted if numeric)
  • main(_) — exactly one arg, unnamed (arity matters, name doesn't)
  • main(*) — any number of args, unnamed
  • main(*args) — any number of args, named
• Define functions top-down: main first, then helpers in call order — this is idiomatic YAMLScript

Function Calls

• Top level: mapping pair — say: 'hello'
• a: b c ≡ a b: c ≡ a b c: — the colon splits a call into before/after segments; choose the split that reads naturally. Promote the "subject" of a call before the colon when it makes the call read like English:
  • write file: content not write: file content
  • assoc m: k v not assoc: m k v
  • join: brackets:seq:shuffle not join: shuffle(seq(brackets))
• Prefer colon-chain composition for unary pipelines. Write x:b:a instead of a(b(x)) when each step takes the previous value as its only argument. This keeps the data flow left-to-right and avoids nested parentheses.
• Higher-order function calls — when the function arg is named, put it on the key side; the data flows to the value:
  • reduce f: init coll — reducing with f over init/coll
  • map double: coll — mapping double over coll
• Inline-defined function for an HOF — put _ where the function arg goes; define the function as the block value:

  reduce _ init coll:
    fn(acc x):
      ...body...
  

  This works for any HOF: map, filter, reduce, etc. The block value substitutes at the _.
• Inline: YeS form — inc(x) not (inc x)
• Prefer a.b(c) over b(a c) — dot chain from the receiver unless the receiver needs escaping ({}, [], "", '')
• Scalar if: dot-chain the condition before it — cond.if(then else) not if(cond then else)
• X OP: Y at the pair level is sugar for X OP Y, for any binary operator. a +: b ≡ a + b; (cond) &&: body ≡ cond && body (body only runs if is truey); ≡ (body only runs if is falsey). The / forms overlap functionally with / but the mechanism is the operator's short-circuit, not a control structure. Scalar must contain exactly one form; a compound expression counts as one form. Mapping values keep their mapping and form-map semantics.

Control Flow

• if <cond>: <then-form> <else-form> — always needs both forms. if is the default for two-branch conditionals. Reach for cond only when there are 3+ branches — see Common Mistakes.

• Use when for one-armed conditional (no else); when-not is the inverted form (when-not X ≡ when X.!). See Common Mistakes for when to choose when/when-not over if/cond.

• when+ expr: — like when, but binds _ to the truey value of expr inside the body. Use it to test-and-capture in one step: when+ schema.'$ref': say: "-type: $(ref-sym(_))"

• .when(value) — receiver acts as the test; returns value if truey, else nil. Replaces the .if(value nil) pattern: only-ref?(s).when(ref-sym(s.'$ref')) not only-ref?(s).if(ref-sym(s.'$ref') nil)

• cond returns nil when no clause matches — drop trailing else: nil

• case requires an explicit else: default arm. Unlike cond (returns nil), case throws No matching clause: <value> if no arm matches. A bare trailing form is parsed as another key: action pair, not a default — else: is required.

• if accepts three shapes:

  • form / form — two consecutive pairs, no keywords: if cond: \n say: yes \n say: no
  • block / block — both then: and else: required; using then: forces else:
  • form / block — bare then-form followed by an else: block. Do NOT use do: for the else block — else: is the idiomatic keyword (see Common Mistakes).

• When both branches are simple, prefer the tersest fit:

Chaining vs Variables vs Block Form

Prefer block form — it often adds clarity that chaining hides. Do not default to chaining just because it is possible. Chaining is fine for short, obvious pipelines; block form is better for anything non-trivial, especially iteration and nested logic.

Avoid over-chaining. A long dot chain on one line is hard to read. Aim to keep chained lines short — 20-60 columns is the natural "square" range. Never exceed 79 columns (see Formatting in Key Rules).

Options when a chain gets long:

• Use block form — nest the argument as an indented block
• Assign intermediate results to named variables
• Split before .call( onto continuation lines (but not before :call)
• A YAML plain scalar can be folded onto multiple lines at any whitespace — the value is still a single expression. For readability, put a binary operator like || or && at the end of the first line and indent the continuation:

  user =: ENV.RC_USER ||
    die('set RC_USER (botpassword username)')
  

  This is a stylistic choice, not a syntactic rule.

Example — chained vs block form for iterating with a nested function:

# Chained — terse but opaque
say: fn([x] sum(digits(x))).iterate(n).drop-while(\(_ >= 10)):first

# Block form — each step is named, reads top-to-bottom
defn main(n=493): !say
  first:
    drop-while ge(10):
      iterate _ n:
        fn(x):
          sum: digits(x)

# Middle ground — intermediate variable + short chain
words =: text:lc.split(/\s+/)
pairs =: words:frequencies.sort-by(val):reverse

Operators & Chaining

• Binary operators require whitespace on both sides — 1 .. 5 not 1..5; a + b not a+b; a * b not a*b. This applies to all binary operators: .. + - * / // || && =~ !~ % %% ** etc. Omitting whitespace may sometimes work but is not idiomatic and may break in future versions. Exception: . (dot chain) does not need whitespace.

• Do NOT mix different operators without parentheses:

  • a * b * c — OK (same operator)
  • a * b + c — NOT OK
  • (a * b) + c — OK

• A chain of the same comparison operator means variadic — not nested: a >= b >= c is (>= a b c), meaning a ≥ b AND b ≥ c, not (a >= b) >= c. Same for ==, <, <=, >, !=.

• Do not parenthesize a binary expression that stands alone as one side of a key/value pair. The pair itself delimits the expression, so wrapping parens are pure noise:

  • (r > 180): r - 360 → r > 180: r - 360
  • x =: (a * b * c) → x =: a * b * c
  • cs =~ /[0-9]/: I(cs) (already correct — no parens needed)

  This applies to both sides of the pair. Parens are still needed when the expression is not standalone — e.g. when it feeds a chain like (d < 10).if(...) or groups mixed operators like (dir == 'w') && (row > 0):.

  The same rule applies to the test position of every conditional / loop control form: if, if-not, when, when-not, while. Each takes its test as a standalone pair-key expression, so the parens are noise:

Values & Data

• For purely literal collections (no code inside), prefer the data-mode toggle =:: over +-escaped code-mode literals. YAML is good at data; let it do that work:

  • a =:: [1, 2, 3] — flow seq, data mode (preferred for literals)
  • a =: +[1 2 3] — code-mode vector literal (use when the collection mixes in computed values, e.g. +[0] + row)

• + escape — needed only when the first non-space character of a YAML value would otherwise be a YAML syntax character ([, {, ", ', |, >, !, &, *). It forces the entire value to parse as a single plain scalar; YS then strips the + and reads the rest as code. The + escape must be at the front of the value and must be followed, possibly after whitespace, by one of those YAML syntax characters. If the next meaningful character is a letter, digit, _, (, or other expression character, the + is not an escape; it is just the plus operator.

  Two distinct reasons + may be needed:

  1. YAML-invalid without it. key: 'a' 'b' — YAML sees 'a' end and 'b' dangle. key: +'a' 'b' makes the whole +'a' 'b' a plain scalar.
  2. YAML-valid but YS-rejected. key: [b c] — valid YAML (flow sequence value), but YAMLScript forbids flow collections and block sequences at code-mode value positions by design. Code mode only needs scalars and block mappings; flow forms are reserved for use as vector/map literals via +-escape. So key: +[b c] is the canonical form.

  + is only needed at the START of a value. Once the value is a plain scalar expression, flow forms inside it are fine as arguments: foo([b c]), map(double [1 2 3]), assoc(m :k [1 2]) all parse without +. The brackets are mid-expression, not at the value start. Do not carry the from into YeS expression position.

Do Semantics

• Top-level, defn, fn bodies have implicit do — rarely need do: explicitly
• YS code blocks are ASTs not mappings — duplicate keys are valid

Eval

• eval(s) / s:eval — parse a string as YS source and run it, returning the value of the final expression. Useful when user input must execute as code: in a 24-game task, the player's expression '(8 - 2) * (7 - 3)':eval returns 24. The string is unrestricted YS, not a sandboxed arithmetic subset, so use it only on trusted input.

I/O, System & Namespaces

• read(path) / path:read — read file contents; write(path content) — write content to file
• say / print / out / warn / err — write to stdout/stderr. say adds a newline; the others do not. warn and err go to stderr; the rest go to stdout. print and out are synonyms (both are clojure.core/print with auto-flush); prefer print when it stands alone, out when chaining or pairing with err.
• To print just a blank line, write bare say: — not say: ''. A valueless say: emits the newline on its own.
• die(msg) — print error message to stderr and exit
• read-line() — read a line from stdin
• IN — stdin handle for read: read: IN instead of slurp: System/in
• trim(s) — strip leading/trailing whitespace
• sleep(n) / sleep: n — pause for n seconds. Use the builtin rather than shelling out via bash-out: "sleep $n".
• bash-out(cmd) / cmd:bash-out — run a shell command and return stdout as a string. Pair with a | block scalar for multi-line scripts; bash continues naturally across newlines after &&, ||, or |, so no trailing \ is needed:

  cmd =: |
    cd work &&
      git rm -fq -- '$rel' &&
      git commit -q -m 'Push $rel' -- '$rel'
  bash-out: cmd
  

  When the command is used only once, pass the heredoc directly: bash-out: | followed by the indented script.
• Filesystem operations live in the fs/ namespace. When a program needs to do anything with the filesystem (test, read metadata, copy, move, remove, etc.), consult https://yamlscript.org/doc/ys-fs/ for the full inventory. Common entries:
  • predicates: (exists?), (file?), (dir?), (link?), // (perms), (empty?)

Anti-Patterns

• Do NOT use =>: for compound expressions — restructure into a pair: =>: a.b.c → a: .b.c; =>: f(a b) → f: a b; =>: a == b → a ==: b. For a cond default arm use else:, not =>:.
• Do NOT use =>: as a direct child of an if. Write then: or else: so the branch role is explicit: if done?: \n then: result, not if done?: \n =>: result.
• Do NOT write x + 1 or x - 1 — use .++ and .--: i.++ not i + 1, (3 * v).++ not ((3 * v) + 1), n.-- not n - 1. Works in chains, args, interpolation, anywhere.
• Do NOT write x ** 2 or x ** 3 — use :sqr and :cube: _:sqr not _ ** 2, n:cube not n ** 3
• Do NOT use do: for the else branch of if — use else:
• Do NOT use cond for two-branch conditionals — cond is for 3+ branches. One predicate + else: is always if: cond: p: a / else: b → if p: \n then: a \n else: b. Scan every cond: and count non-else: clauses; if it's one, rewrite as if.
• Do NOT write lines longer than 79 columns. Use block form, intermediate variables, plain scalar folding, or double-quoted \ continuation to split (see Formatting in Key Rules).
• Do NOT add :int / :N coercion to numeric CLI args in main. YS auto-converts numeric-looking CLI args; coercion is dead code.
• Do NOT use str() for string building — use interpolation or +
• Do NOT use Lisp style — use or pair form

Reference

Key docs in the YAMLScript repo:

• doc/clj-to-ys.md — Clojure to YS conversion tutorial
• doc/cheat.md — Quick syntax reference
• doc/yes.md — YeS expressions
• doc/chain.md — Dot chaining
• doc/operators.md — Operators

Session logs with confirmed examples: skill/sessions/