@@ -1,238 +0,0 @@
1−---
2−navhome: /docs
3−next: true
4−sort: 3
5−title: Glossary of Urbit Terms
6−---
7−
8−# Glossary of Urbit Terms
9−
10−Here is a simple overview of the most common Urbit terms. Once you understand this, you know almost everything you need to start using Urbit.
11−
12−## The Universe in a Table
13−
14− Size Name Parent Object Example
15− ----- ------ ------ ------ -------
16− 2^8 galaxy ~ datacenter ~zod
17− 2^16 star galaxy sysadmin ~doznec
18− 2^32 planet star user ~tasfyn-partyv
19− 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
20− 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
21− any urbit * * ~somnym-anynym
22−
23−> The below summary is also available [here](http://urbit.org/posts/address-space/).
24−
25−An Urbit identity is a string like `~firbyr-napbes`. It
26−means nothing, but it's easy to remember and say out loud.
27−`~firbyr-napbes` is actually just a 32-bit number, like an IP address,
28−that we turn into a human-memorable string.
29−
30−Technically, an urbit is a secure digital identity that you own and
31−control with a cryptographic key, like a Bitcoin wallet. As in
32−Bitcoin, the supply of urbits is mathematically limited. This keeps
33−the network friendly, by making spam and abuse expensive.
34−
35−An urbit name is just a number; smaller numbers make shorter names.
36−Shorter names are easier to remember, so they're more valuable. So
37−urbits are classified by the number of bits in their name. (A ship
38−name is just a scrambled base-256 representation of the number.)
39−
40−A 32-bit urbit (like `~firbyr-napbes`) is called a "planet." A 16-bit
41−urbit (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
42−"galaxy." A planet is an identity for an independent, adult human.
43−Stars and galaxies are network infrastructure.
44−
45−Each planet or star is launched by its "parent," the star or galaxy
46−whose number is its bottom half. So the planet `~firbyr-napbes`,
47−`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`
48−or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of
49−`~mun` and all galaxies is `~zod`, `0`.
50−
51−### Nock
52−
53−> Nock is a Turing-complete, non-lambda combinator function.
54−
55−- A `noun` is an `atom` or a `cell`.
56−- An `atom` is any natural number.
57−- A `cell` is an ordered pair of `noun`s.
58−- `subject`: a `noun` - the argument against which a `formula` is evaluated
59−- `formula`: a `noun` - any of the Hoon formula numbers (0-10), followed by *(TODO: ?)*
60−- `product`: a `noun` - the result of evaluating a `formula` against a `subject`
61−
62−*See [Nock definition](/nock/definition/)*
63−
64−### Hoon
65−
66−> Hoon is a strict, higher-order typed functional language which compiles itself to Nock.
67−
68−###### `span`: an inferred type
69−
70−A `span` defines a set (finite or infinite) of `noun`s and ascribes some semantics to it. There is no Hoon syntax for a `span`; it is always produced as the inferred range of an expression (`twig`).
71−
72−*See [basic types](/hoon/basic)*
73−
74−###### `mold`: a type constructor / validator
75−
76−A mold is an idempotent `gate` (function), accepting any `noun` and normalizing it to a range.
77−
78−- `icon`: the `span` of a `mold`
79−- `bunt`: *(TODO: ??)*
80−
81−*See [`mold`](hoon/twig/buc-mold/)*
82−
83−###### `gate`: a function, lambda or closure
84−
85−*TODO: simplify description*
86−
87−A `gate` is a specialized `core` with only one arm (whose name is the empty string (the symbol `$`). To call a `gate` on an argument, replace the `sample` (at tree address `6` in the `core`) with the argument, and then compute the `arm`.
88−
89−The `payload` of a `gate` has a shape of `{sample context}`.
90−
91−- `sample`: the argument *(TODO: or plural?)* of a `gate`
92−- `context`: the subject in *(TODO: against?)* which a `gate` was defined
93−
94−*See [basic types](/hoon/basic)*
95−
96−###### `arm`: a named, functionally-computed attribute of a `core`
97−
98−The `twig` of each `arm` is compiled to a Nock formula, with the enclosing `core` itself as the subject.
99−
100−*See [basic types](/hoon/basic)*
101−
102−###### `core`: a code-data `cell`
103−
104−The code (`battery`) is the head, the data (`payload`) is the tail. All code-data structures in normal languages (functions, objects, modules, etc) become `core`s in Hoon.
105−
106−- `battery`: the code of a `core`, a tree of `arm`s
107−- `payload`: the data in a `core`
108−
109−`core`s are *polymorphic* structures; every function call (`gate`) in Hoon replaces the `payload` of a `core` with a different `noun`, and then invokes an `arm` from the `battery`.
110−
111−- `wet`: polymorphic by means of *genericity*
112−
113−*TODO: simplify*
114−
115−> When we call a `wet` `arm`, we're essentially using the `twig` as a macro. We are not generating new code for every call site; we are creating a new type analysis path, which works as if we expanded the callee with the caller's context.
116−
117−- `dry`: polymorphic by means of *variance*
118−
119−For a `dry` `arm`, we ask, is the new `payload` compatible with the old `payload` (against which the `core` was compiled)?
120−
121−Every `dry` `core` has a `metal` *(TODO: check)* which defines its *variance* model (ie, the properties of the `span` of a compatible `core`).
122−
123−*TODO: is the core dry, the arm dry, or both?*
124−
125−- `gold`: *invariant*
126−- `lead`: *bivariant*
127−- `zync`: *covariant*
128−- `iron`: *contravariant*
129−
130−*See [advanced types](/hoon/advanced)*
131−
132−###### `foot`: a `wet` or `dry` `twig`
133−
134−*TODO: any `twig`, or always an `arm` within a `battery`?*
135−
136−###### `atom`
137−
138−A Hoon `atom` is a Nock `atom`, with two additional pieces of metadata (TODO: ?): an `aura`, and a `unit`.
139−
140−- `unit`: a nullable pointer (TODO: ?), or a Maybe
141−
142−`atom`s are said to be `warm` or `cold` based on their `unit`
143−
144−- `warm`: if the `unit` is `~` (null), any `atom` is in the `span`
145−- `cold`: if the `unit` is `[~ x]`, where `x` is any `atom`, its only legal value is the constant `x`. *(TODO: what does this actually mean? What is the consequence of illegality?)*
146−
147−###### `aura`: a soft `atom` type
148−
149−*alternately `odor`*
150−
151−*TODO: write a short summary*
152−
153−*TODO: are `aura`s always `mold`s? just the built-in `aura`s?*
154−
155−> Auras are a lightweight, advisory representation of the units, semantics, and/or syntax of an `atom`. An `aura` is an atomic string; two auras are compatible if one is a prefix of the other.
156−>
157−> For instance, @t means UTF-8 text (LSB low), @ta means ASCII text, and @tas means an ASCII symbol. @u means an unsigned integer, @ud an unsigned decimal, @ux an unsigned hexadecimal. You can use a @ud atom as a @u or vice versa, but not as a @tas.
158−>
159−> Auras are truly soft; you can turn any `aura` into any other, statically, by casting through the empty `aura` `@`. Hoon is not dependently typed and can't statically enforce data constraints (for example, it can't enforce that a `@tas` is really a symbol).
160−>
161−
162−- `term` (`@tas`): a symbol - an atomic ASCII string which obeys symbol rules: lowercase and digit only, infix hyphen ("worm-case"), first character must be lowercase *(TODO: alphabetic?)*.
163−
164−- `cord` (`@t`): UTF-8 text, least-significant-byte first
165−
166−- `char` (`@tD`): a character, a single unicode byte (for multi-byte characters and codepoints, see `@c`)
167−
168−- `tape` (`(list char)`): a `tape` is not an `aura`, but a `mold` for a collection where every item has an `aura` of `char` *(TODO: is this for easy indexing vs `@t`?)*
169−
170−*See [basic types](/hoon/basic)*
171−
172−###### `loobean`: a Hoon boolean
173−
174−`0` (`%.y`) is *true*, `1` (`%.n`) is *false*.
175−
176−> Why? It's functional: good code has `0` side effects.
177−
178−###### `twig`: a Hoon expression
179−
180−A `twig` is the name for any Hoon expression, and for the AST node representing the expression as compiled to Nock formula *(TODO: seems to be used interchangeably in the docs)*. It is a `book` with the form `{stem bulb}`.
181−
182−- `book`: a tagged-union
183−- `page`: an item in a `book`
184−- `stem`: an atomic symbol (`@tas`) - uniquely identifies a `twig` *(TODO: ?)*
185−- `bulb`: The `bulb` for each `stem` has its own type, usually a tuple, sometimes a list or a map.
186−
187−A `twig` is either a `moss` ("mossy") or a `seed` ("woody"):
188−
189−- `moss`: a `twig` whose `product` is used a `mold`
190−- `seed`: a `twig` whose `product` could by anything
191−
192−The vast majority of `twig`s have a *regular form*, beginning with either a keyword `sigil` or a digraph `rune`. Some `twig`s also have a syntactic *irregular form*, a handful have only an *irregular form*.
193−
194−- `sigil`: a keyword used to begin a `twig`
195−
196−Hoon does not have reserved words, but `sigil`s (prefixed with `:`), which are effectively aliases for `rune`s. For example, [`:cons` is `:-`](/hoon/twig/col-cel/hep-cons).
197−
198−- `rune`: a pair of ASCII symbols used to begin a `twig` - the first symbol represents a family of related `twig`s. For example, the [`:` family](/hoon/twig/col-cell/) are all for cell-construction.
199−
200−*See [`twig` concept](/hoon/concepts) and [expressions](/hoon/twig/)*
201−
202−###### `limb`: attribute or variable reference
203−
204−To resolve a `limb` named "foo", the `subject` is searched depth-first, head-first for either a `face` named "foo" or a `core` with an `arm` of "foo". If a `face` is found, the result is a `leg`, if a `core` is found, the result is the `product` of the `arm`.
205−
206−- `leg`: a subexpression, or subtree of the `subject`. usually another `twig`, sometimes a symbol (`@tas`) or `wing`
207−- `wing`: a list of `limb`s
208−
209−*See [Limbs and wings](/hoon/twig/limb)*
210−
211−###### `face`: a named variable
212−
213−Hoon has no scope or symbol-table; there is only the `subject`. To "declare" a "variable" is to construct a new `subject`: `[variable old-subject]`.
214−
215−A `face` is a `span` *(TODO: ?)* with a label (`@tas`) wrapped around it.
216−
217−- `taco`: a `symbol` (for a *type-inferred* `face`), or a `symbol` *with* a `mold` (for a *type-checked* `face`)
218−
219−*TODO: check these*
220−
221−- `tune`: advanced `face`s:
222− - `alias`: a `face` that is a lazy reference to another `face`
223− - `bridge`: a `face` that references a `twig`, against which the `face` label is resolved
224−
225−*See [advanced types](/hoon/advanced)*
226−
227−###### `nest`: a type-casting operation
228−
229−*TODO:*
230−
231−### Arvo
232−
233−> Arvo is a nonpreemptive OS kernel, a single-threaded event interpreter.
234−
235−- `mark`
236−- `generator`
237−
238−*... TODO*