Nim

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

.nim, .nims, .nimble

Registry names

nim

Recorded symbols

functions · types · macros · methods

Relationship types this analyzer constructs

12 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.

12 constructed, 2 not constructed. All 2 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

• The engine's language table declares nim twice — tree-sitter-nim and then __generic__ — and the second entry shadows the first. Both the grammar and the analyzer are wired into getAnalyzer, but a .nim file is currently routed away from them.
• implements is structurally absent, and that is a fact about Nim: a concept is duck-typed rather than nominal, so there is no declaration for an edge to point at. The differential reports the label as vacuous rather than pretending it is covered.
• Cross-file override resolution reads a companion index that carries owner to member names but not each type's own base list, so the walk descends only as far as bases visible in the current file: a hierarchy three modules deep stops at the visible link.

Every line above was written against Nim’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 — .nim, .nims, .nimble. Everything below is about where those files actually sit in a working repository.

• A Nim project mixes library modules with per-project source and a .nimble package file that names its dependencies.
• include pastes one file into another at compile time, so a symbol can be declared in a file that never imports it.
• Nim spells the same idea seven different ways — proc, func, method, iterator, converter, template, macro — so a search for one name has to account for which keyword introduced it.

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. Which routines does this file declare, and which keyword spelled each one?
2. Which types and fields does this module define?
3. Which modules does this file import from, and which names does it take?
4. Which method on this receiver overrides which?

What the analyzer sees in code like this

type
  Vec*[T] = ref object of Base   ## bb records: class Vec (a ref object) · extends Base
    x, y: T                      ## bb records: the fields x and y

method describe(d: Vec[int]): string =   ## bb records: a method on Vec
  result = $d.x

template twice(x: untyped): untyped =   ## bb records: a template, kept as a macro kind
  x; x

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

Functional & declarative — the count beside each name is how many relationship types that family’s analyzer constructs.

• Elixir10 types
• Clojure11 types
• Haskell12 types
• Scala11 types
• Erlang9 types
• F#11 types
• Clean9 types
• Julia11 types
• MATLAB11 types
• Solidity11 types