Skip to content

Language record

YAML

YAML is read structurally: a mapping key becomes a property, an object-valued key a container, a sequence-valued key a list, and an anchor a named constant that the aliases in its own document point at — with merge keys recorded as inheritance and cross-document aliases recorded as failures with a stated reason.

.yml, .yaml · 1 registry id · 8 of 14 relationship types

The registry row this page is generated from

Read at render time from the same family row the register reads, so nothing in this block can disagree with it.

Extensions
.yml, .yaml
Registry names
yaml
Recorded symbols
keys · nesting · anchors · merge keys

Relationship types this analyzer constructs

8 of 14 constructed, read from this analyzer's source and re-derived by the languages gate. Each row below is one of the engine's types, in the engine's own order.

Relationship typeConstructed
callsconstructed by this analyzer
extendsconstructed by this analyzer
implementsruled absent
usesconstructed by this analyzer
importsconstructed by this analyzer
exportsconstructed by this analyzer
containsconstructed by this analyzer
referencesconstructed by this analyzer
overridesconstructed by this analyzer
instantiatesruled absent
decoratesruled absent
rendersruled absent
mixes_inruled absent
part_ofruled absent

8 constructed, 6 not constructed. All 6 absent types are recorded as ruled absent: the written reason and the corpus measurement behind each are in this family's completeness record. The register explains what each label means.

What this analyzer does not resolve

  • An alias resolves inside its own document, and the two failure modes are distinguished rather than pooled. An anchor declared in another document is stored at 0.5 with the reason anchor-defined-in-another-document; an anchor nothing declares is 0.8 with anchor-not-declared. Inside one document the nearest definition wins, which is what the specification says.
  • An include is a closed list of ten spellings, and that list was measured rather than guessed: across 9,953 files in eight pinned corpora every one of the ten occurs zero times, while the tags Ansible actually uses are not on it. A template tag outside the list produces no import, and a uses: key is treated as an import only when the file's shape says GitHub workflow.
  • A templated YAML file is where this lane stops. For files whose root node is an ERROR the parse tree covers roughly 28–31% of the document, so a heavily templated manifest publishes a fraction of its keys — and each recovered symbol is flagged with the line and width it was recovered through, so a partial publish is visible rather than mistaken for a short document.

Every line above was written against YAML’s own analyzer module and is named against a construct in it, so it can be checked against the source. Nothing here is inherited from a template, or from another language’s page.

Where you meet it in a repository

Recognised by extension — .yml, .yaml. Everything below is about where those files actually sit in a working repository.

  • CI workflows, compose files, Helm values and Kubernetes manifests are all YAML and all index as one family — a services: key means nothing in particular until you know which file it came from.
  • Anchors and aliases are the YAML-specific case: a shared block written once as &base and reused as *base shows up as one anchor plus the keys that reference it, within that document only. A merge key << inherits INTO the object that contains it, so the edge leaves the container rather than the key.
  • A multi-document file (--- separated) is one file with several roots, each named <stem> or <stem>#<n>, so a key repeated in each document is a separate record under its own document path rather than a duplicate of the first.

Questions this index answers

Phrased as retrievals, because that is what an index can honestly do: it holds the symbols and the edges between them, and hands them back with the evidence attached.

  1. What keys does this document declare, and how are they nested?
  2. Where is this key set, and what sits under it?
  3. Which sequence items live beneath this key?
  4. Which anchor does this alias resolve to, and did it resolve at all?

What the analyzer sees in code like this

A scalar key, an object container, a sequence-valued key and an anchor
version: "3.9"                    # bb records: property version
services:                         # bb records: container services (object-valued key)
  api:                            # bb records: property api, owned by services
    image: acme/api                # an anonymous scalar: readable, but no symbol of its own
    ports: ["8080:80"]             # bb records: variable ports (sequence-valued key)
defaults: &base                   # bb records: constant base — the anchor

Symbols are stored with the file they came from and the bytes they span, so a hit points at a line rather than at a guess. The annotations in the sample are commentary for the reader, not strings the index would store.

Languages that turn up in the same repository

Web, data & config — the count beside each name is how many relationship types that family’s analyzer constructs.

The extensions, registry names, recorded symbols and relationship types above are the parser registry row for YAML, read while the page rendered — the same row the register reads, so the two surfaces cannot tell two stories. Every relationship type listed as constructed appears in src/ast/real-*, the analyzer modules bb ships. bb 0.1.0 answers from a local store over 50 languages (53 registry ids, three of them aliases). There is no benchmark on this page: every claim here is one you can go and read in the source.