Erlang

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

.erl, .hrl

Registry names

erlang

Recorded symbols

modules · functions · macros · typespecs

Relationship types this analyzer constructs

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

9 constructed, 5 not constructed. All 5 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

• Macros are not expanded: only an object-like -define(NAME, atom) is readable without a preprocessor, and a clause headed by any other macro declares nothing rather than being guessed at.
• Erlang has no inheritance, so there is no extends and no override edge at all. A behaviour is a cross-module contract, and nothing in the format says one function replaces another.
• In type syntax a bare unquoted atom is the atom literal of that name, never a type called by that name — you must write foo() to apply a type. Only an applied name produces a type reference, which is why #state.count inside a -spec yields an edge and a bare count does not.

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

• An OTP application is many small modules that talk by message passing, so the interesting graph is the callback contract rather than the call graph.
• A .hrl header holds the records and types that every module in the release shares.
• A function's identity is its name and arity, so pick/0 and pick/1 are two symbols and every clause of one pair merges into a single entry.

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 behaviours does this module implement?
2. Which callbacks does this module promise?
3. Which macros does this module define?
4. Which record fields does this state hold, and what types are they?

What the analyzer sees in code like this

-module(my_server).                 % bb records: module my_server
-behaviour(gen_server).             % bb records: implements gen_server
-record(state, {orders = [] :: list()}).

init([]) -> {ok, #state{}}.        % bb records: function init/1
place(Order) -> lists:sort([Order]).  % bb records: a remote call to lists:sort

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
• F#11 types
• Clean9 types
• Nim12 types
• Julia11 types
• MATLAB11 types
• Solidity11 types