@@ -1,24 +1,23 @@
11---
2−navhome: /docs
3−next: true
2+navhome: '/docs'
3+next: True
44sort: 3
55title: Urbit glossary
66---
77
88# Urbit glossary
99
10−Urbit is renowned for its exotic terminology. Here's a simple
11−overview from the strange words in.
10+Urbit is renowned for its exotic terminology. Here's a simple overview
11+from the strange words in.
1212
13−As Dijkstra put it: "The purpose of abstraction is not to be
14−vague, but to create a new semantic level in which one can be
15−absolutely precise."
13+As Dijkstra put it: "The purpose of abstraction is not to be vague, but
14+to create a new semantic level in which one can be absolutely precise."
1615
1716## Ships
1817
19−An Urbit `ship` is a cryptographic identity, a human-memorable
20−name, and a packet routing address. Ships are classed by the
21−number of bits in their address:
18+An Urbit `ship` is a cryptographic identity, a human-memorable name, and
19+a packet routing address. Ships are classed by the number of bits in
20+their address:
2221
2322 Size Name Parent Object Example
2423 ----- ------ ------ ------ -------
@@ -32,66 +31,68 @@ Any ship can be called an `urbit`.
3231
3332> A summary [here](http://urbit.org/posts/address-space/).
3433
35−An Urbit identity is a string like `~firbyr-napbes`. It
36−means nothing, but it's easy to remember and say out loud.
37−`~firbyr-napbes` is actually just a 32-bit number, like an IP address,
38−that we turn into a human-memorable string.
34+An Urbit identity is a string like `~firbyr-napbes`. It means nothing,
35+but it's easy to remember and say out loud. `~firbyr-napbes` is actually
36+just a 32-bit number, like an IP address, that we turn into a
37+human-memorable string.
3938
4039Technically, an urbit is a secure digital identity that you own and
41−control with a cryptographic key, like a Bitcoin wallet. As in
42−Bitcoin, the supply of urbits is mathematically limited. This keeps
43−the network friendly, by making spam and abuse expensive.
40+control with a cryptographic key, like a Bitcoin wallet. As in Bitcoin,
41+the supply of urbits is mathematically limited. This keeps the network
42+friendly, by making spam and abuse expensive.
4443
4544An urbit name is just a number; smaller numbers make shorter names.
46−Shorter names are easier to remember, so they're more valuable. So
47−urbits are classified by the number of bits in their name. (A ship
48−name is just a scrambled base-256 representation of the number.)
45+Shorter names are easier to remember, so they're more valuable. So
46+urbits are classified by the number of bits in their name. (A ship name
47+is just a scrambled base-256 representation of the number.)
4948
5049A 32-bit urbit (like `~firbyr-napbes`) is called a "planet." A 16-bit
5150urbit (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
52−"galaxy." A planet is an identity for an independent, adult human.
53−Stars and galaxies are network infrastructure.
51+"galaxy." A planet is an identity for an independent, adult human. Stars
52+and galaxies are network infrastructure.
5453
5554Each planet or star is launched by its "parent," the star or galaxy
56−whose number is its bottom half. So the planet `~firbyr-napbes`,
57−`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef`
58−or `48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of
59−`~mun` and all galaxies is `~zod`, `0`.
55+whose number is its bottom half. So the planet `~firbyr-napbes`,
56+`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
57+`48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of `~mun`
58+and all galaxies is `~zod`, `0`.
6059
6160### Nock
6261
6362> Nock is a Turing-complete, non-lambda combinator interpreter.
6463
65−- `noun`: an `atom` or a `cell`
66−- `atom`: any natural number
67−- `cell`: any ordered pair of `noun`s
68−- `subject`: a `noun` - the data against which a `formula` is evaluated
69−- `formula`: a `noun` - a function at the Nock level
70−- `product`: a `noun` - the result of evaluating a `formula` against a `subject`
64+- `noun`: an `atom` or a `cell`
65+- `atom`: any natural number
66+- `cell`: any ordered pair of `noun`s
67+- `subject`: a `noun` - the data against which a `formula` is
68+ evaluated
69+- `formula`: a `noun` - a function at the Nock level
70+- `product`: a `noun` - the result of evaluating a `formula` against a
71+ `subject`
7172
7273*See [Nock definition](../../nock/definition/).*
7374
7475### Hoon
7576
76−> Hoon is a strict, higher-order typed functional language that compiles itself to Nock.
77+> Hoon is a strict, higher-order typed functional language that compiles
78+> itself to Nock.
7779
7880###### `span`: an inferred type
7981
80−A `span` defines a set (finite or infinite) of `noun`s and
81−ascribes some semantics to it. There is no Hoon syntax for a
82−`span`; it is always produced as the inferred range of an
83−expression (`twig`).
82+A `span` defines a set (finite or infinite) of `noun`s and ascribes some
83+semantics to it. There is no Hoon syntax for a `span`; it is always
84+produced as the inferred range of an expression (`twig`).
8485
8586*See [basic types](../../hoon/basic/#-type-span-and-mold).*
8687
8788###### `core`: a code-data `cell`
8889
89−The code (`battery`) is the head, the data (`payload`) is the
90−tail. All code-data structures in normal languages (functions,
91−objects, modules, etc) become `core`s in Hoon.
90+The code (`battery`) is the head, the data (`payload`) is the tail. All
91+code-data structures in normal languages (functions, objects, modules,
92+etc) become `core`s in Hoon.
9293
93−- `battery`: the code of a `core`, a tree of `arm`s
94−- `payload`: the data in a `core`
94+- `battery`: the code of a `core`, a tree of `arm`s
95+- `payload`: the data in a `core`
9596
9697*See [basic types](../../hoon/basic)*.
9798
@@ -100,150 +101,154 @@ objects, modules, etc) become `core`s in Hoon.
100101The `twig` of each `arm` is compiled to a Nock formula, with the
101102enclosing `core` itself as the subject.
102103
103−There are two kinds of `arm`s: `dry` and `wet`. Most arms are
104−dry.
104+There are two kinds of `arm`s: `dry` and `wet`. Most arms are dry.
105105
106−- `dry`: normal, `++`, polymorphic by means of *variance*
106+- `dry`: normal, `++`, polymorphic by means of *variance*
107107
108−For a `dry` `arm`, we ask, is the new `payload` compatible with
109−the old `payload` (against which the `core` was compiled)?
108+For a `dry` `arm`, we ask, is the new `payload` compatible with the old
109+`payload` (against which the `core` was compiled)?
110110
111−- `wet`: unusual, `+-`, polymorphic by means of *genericity*
111+- `wet`: unusual, `+-`, polymorphic by means of *genericity*
112112
113−A `wet` `arm` uses the `twig` as a macro. We create a new type
114−analysis path, which works as if we expanded the callee with the
115−caller's context.
113+A `wet` `arm` uses the `twig` as a macro. We create a new type analysis
114+path, which works as if we expanded the callee with the caller's
115+context.
116116
117117*See [advanced types](/hoon/advanced)*.
118118
119119###### `metal`: a variance model
120120
121−Every `core` has a `metal` which defines its *variance* model
122−(ie, the properties of the `span` of a compatible `core`).
123−The default is `gold` (invariant).
121+Every `core` has a `metal` which defines its *variance* model (ie, the
122+properties of the `span` of a compatible `core`). The default is `gold`
123+(invariant).
124124
125−- `gold`: *invariant*
126−- `lead`: *bivariant*
127−- `zinc`: *covariant*
128−- `iron`: *contravariant*
125+- `gold`: *invariant*
126+- `lead`: *bivariant*
127+- `zinc`: *covariant*
128+- `iron`: *contravariant*
129129
130130*See [advanced types](/hoon/advanced)*.
131131
132132###### `gate`: a function/lambda/closure
133133
134−A `gate` is a `core` with one `arm`. To call a `gate` on an
135−argument, replace the `sample` (at tree address `6` in the
136−`core`) with the argument, and then compute the `arm`.
134+A `gate` is a `core` with one `arm`. To call a `gate` on an argument,
135+replace the `sample` (at tree address `6` in the `core`) with the
136+argument, and then compute the `arm`.
137137
138138The `payload` of a `gate` has a shape of `{sample context}`.
139139
140−- `sample`: the argument tuple
141−- `context`: the subject in which the `gate` was defined
140+- `sample`: the argument tuple
141+- `context`: the subject in which the `gate` was defined
142142
143−*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span), [`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for calling a `gate`).*
143+*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span),
144+[`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for
145+calling a `gate`).*
144146
145147###### `mold`: a type constructor / validator
146148
147−A mold is an idempotent `gate` (function), accepting any `noun`,
148−and producing a range with a useful `span`.
149+A mold is an idempotent `gate` (function), accepting any `noun`, and
150+producing a range with a useful `span`.
149151
150−- `bunt`: the value a `mold` produces when normalizing its default sample
151−- `icon`: the `span` of the `mold`'s range
152+- `bunt`: the value a `mold` produces when normalizing its default
153+ sample
154+- `icon`: the `span` of the `mold`'s range
152155
153156*See [`mold` `twig`s](/hoon/twig/buc-mold/).*
154157
155158###### `atom`
156159
157−A Hoon `atom` span describes a Nock `atom`, with two additional
158−pieces of metadata: an `aura`, and an optional constant.
160+A Hoon `atom` span describes a Nock `atom`, with two additional pieces
161+of metadata: an `aura`, and an optional constant.
159162
160−An `atom` span is `warm` or `cold` based on whether the constant
161−exists.
163+An `atom` span is `warm` or `cold` based on whether the constant exists.
162164
163−- `warm`: if the constant is `~` (null), any `atom` is in the `span`
164−- `cold`: if the constant is `[~ atom]`, its only legal value is `atom`.
165+- `warm`: if the constant is `~` (null), any `atom` is in the `span`
166+- `cold`: if the constant is `[~ atom]`, its only legal value is
167+ `atom`.
165168
166169*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*
167170
168171###### `aura`: a soft `atom` type
169172
170−`aura` is a name for an atom type. It represents the structure of
171−an `atom` in a string beginning with `@`. An aura may represent
172−units, print format, or other semantics. Its constraints on the
173−value of an atom aren't enforced in any way.
173+`aura` is a name for an atom type. It represents the structure of an
174+`atom` in a string beginning with `@`. An aura may represent units,
175+print format, or other semantics. Its constraints on the value of an
176+atom aren't enforced in any way.
174177
175−Two `aura`s are compatible if one is a prefix of the other. You
176−can change any `aura` into any other `aura` by casting through
177−the empty `aura`, `@`. The standard library has molds which
178−alias many common auras.
178+Two `aura`s are compatible if one is a prefix of the other. You can
179+change any `aura` into any other `aura` by casting through the empty
180+`aura`, `@`. The standard library has molds which alias many common
181+auras.
179182
180183Some common auras and their aliases:
181184
182−- `term` (`@tas`): a symbol - an atomic ASCII string which obeys symbol rules: lowercase and digit only, infix hyphen ("kebab-case"), first character must be lowercase alphabetic.
183−- `cord` (`@t`): UTF-8 text, least-significant-byte first
184−- `char` (`@tD`): a character, a single unicode byte (for multi-byte characters and codepoints, see `@c`)
185+- `term` (`@tas`): a symbol - an atomic ASCII string which obeys
186+ symbol rules: lowercase and digit only, infix hyphen ("kebab-case"),
187+ first character must be lowercase alphabetic.
188+- `cord` (`@t`): UTF-8 text, least-significant-byte first
189+- `char` (`@tD`): a character, a single unicode byte (for multi-byte
190+ characters and codepoints, see `@c`)
185191
186192*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*.
187193
188194###### `twig`: a Hoon expression
189195
190−A `twig` is a Hoon expression. Specifically, `twig` is the mold
191−for the noun that a Hoon source expression compiles to. A twig
192−is always a cell.
196+A `twig` is a Hoon expression. Specifically, `twig` is the mold for the
197+noun that a Hoon source expression compiles to. A twig is always a cell.
193198
194−A twig has one of two forms: `{twig twig}`, which produces the
195−ordered pair of the two twigs, or a cell `{stem bulb}`, where
196−`stem` is an atomic symbol.
199+A twig has one of two forms: `{twig twig}`, which produces the ordered
200+pair of the two twigs, or a cell `{stem bulb}`, where `stem` is an
201+atomic symbol.
197202
198−- `stem`: an atomic symbol (`@tas`) - the name of a `twig`.
199−- `bulb`: The `mold` of the `twig`'s contents.
203+- `stem`: an atomic symbol (`@tas`) - the name of a `twig`.
204+- `bulb`: The `mold` of the `twig`'s contents.
200205
201−Most `twig`s have a *regular form*, beginning with a `sigil`
202−which is either a `keyword` or a `rune`. Some `twig`s also have
203−a syntactic *irregular form*; a few have *only* an *irregular
204−form*.
206+Most `twig`s have a *regular form*, beginning with a `sigil` which is
207+either a `keyword` or a `rune`. Some `twig`s also have a syntactic
208+*irregular form*; a few have *only* an *irregular form*.
205209
206−- `sigil`: a `keyword` or `rune` used to begin a `twig`
207−- `keyword`: the value of a stem, prefixed with `:`.
208−- `rune`: a pair of ASCII symbols used to begin a `twig`.
210+- `sigil`: a `keyword` or `rune` used to begin a `twig`
211+- `keyword`: the value of a stem, prefixed with `:`.
212+- `rune`: a pair of ASCII symbols used to begin a `twig`.
209213
210214For example, the stem `%if` becomes the keyword
211−[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`.
212−The first symbol in a rune represents a family of related
213−`twig`s. For example, the [`?` family](../../hoon/twig/wut-test/)
214−are all conditionals.
215+[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`. The first
216+symbol in a rune represents a family of related `twig`s. For example,
217+the [`?` family](../../hoon/twig/wut-test/) are all conditionals.
215218
216−The keyword or rune forms are up to the programmer's choice.
217−Most existing code uses runes, but the keyword form makes the
218−learning path easier.
219+The keyword or rune forms are up to the programmer's choice. Most
220+existing code uses runes, but the keyword form makes the learning path
221+easier.
219222
220223A regular twig has two syntactic forms, *tall* and *flat*:
221224
222−- `tall`: multiple lines, no parentheses, two or more spaces between tokens
223−- `flat`: one line, parentheses, one space between tokens
225+- `tall`: multiple lines, no parentheses, two or more spaces between
226+ tokens
227+- `flat`: one line, parentheses, one space between tokens
224228
225−`tall` twigs can contain `flat` ones, but not vice versa. All
226−irregular forms are `flat`.
229+`tall` twigs can contain `flat` ones, but not vice versa. All irregular
230+forms are `flat`.
227231
228−*See [`twig` concept](../../hoon/concepts/#-twig-expression), [expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
232+*See [`twig` concept](../../hoon/concepts/#-twig-expression),
233+[expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
229234
230235###### `limb`: attribute or variable reference
231236
232−To resolve a `limb` named "foo", the `subject` is searched
233−depth-first, head-first for either a `face` named "foo" or a
234−`core` with an `arm` of "foo". If a `face` is found, the result
235−is a `leg`, if a `core` is found, the result is the `product` of
236−the `arm`.
237+To resolve a `limb` named "foo", the `subject` is searched depth-first,
238+head-first for either a `face` named "foo" or a `core` with an `arm` of
239+"foo". If a `face` is found, the result is a `leg`, if a `core` is
240+found, the result is the `product` of the `arm`.
237241
238−- `leg`: a subexpression, or subtree of the `subject`.
239−- `wing`: a list of `limb`s, searched from right to left (`a.b` means `b` within `a`).
242+- `leg`: a subexpression, or subtree of the `subject`.
243+- `wing`: a list of `limb`s, searched from right to left (`a.b` means
244+ `b` within `a`).
240245
241246*See [Limbs and wings](../../hoon/twig/limb)*
242247
243248###### `face`: a labeled subtree
244249
245−Hoon has no scope or symbol-table; there is only the `subject`.
246−To "declare" a "variable" is to construct a new `subject`:
250+Hoon has no scope or symbol-table; there is only the `subject`. To
251+"declare" a "variable" is to construct a new `subject`:
247252`[name=value old-subject]`.
248253
249254A `face` is a `span` that wraps a name (`@tas`) around another `span`.
@@ -252,9 +257,8 @@ A `face` is a `span` that wraps a name (`@tas`) around another `span`.
252257
253258###### `nest`: type compatibility test
254259
255−`nest` is an internal function on two spans, which produces yes
256−if the set of nouns in the second span is provably a subset of
257−the first.
260+`nest` is an internal function on two spans, which produces yes if the
261+set of nouns in the second span is provably a subset of the first.
258262
259263*See [advanced types](../../hoon/advanced/)*.
260264
@@ -262,6 +266,5 @@ the first.
262266
263267`0` (`%.y`) is *yes*, `1` (`%.n`) is *no*.
264268
265−> Why? It's fresh, it's different, it's new. And it's annoying.
266−> And it keeps you on your toes. And it's also just intuitively
267−> right.
269+> Why? It's fresh, it's different, it's new. And it's annoying. And it
270+> keeps you on your toes. And it's also just intuitively right.