@@ -0,0 +1,850 @@
1++++
2+title = "Glossary"
3+weight = 3
4+template = "doc.html"
5+aliases = ["docs/reference/arvo-glossary/"]
6++++
7+
8+Urbit is renowned for its exotic terminology. Here's a simple overview
9+from the strange words within.
10+
11+As Dijkstra put it: "The purpose of abstraction is not to be vague, but
12+to create a new semantic level in which one can be absolutely precise."
13+
14+This glossary only covers terms the Arvo side of the project. You can find the
15+Azimuth glossary [here](../azimuth/glossary)
16+
17+### application
18+
19+Also known as an “app,” an _application_ is a Hoon program that can hold state.
20+
21+### arm
22+
23+An _arm_ is a named, functionally-computed attribute of a [core](#core).
24+
25+The [hoon](#a-hoon) of each arm is compiled to a Nock formula, with the
26+enclosing [core](#core) itself as the subject.
27+
28+There are two kinds of arms: _dry_ and _wet_. Most arms are
29+dry.
30+
31+#### dry
32+
33+ normal, `++`, polymorphic by means of _variance_
34+
35+ For a dry arm, we ask: is the new payload compatible with the old
36+ payload (against which the core was compiled)?
37+
38+#### wet
39+
40+ unusual, `+-`, polymorphic by means of _genericity_
41+
42+ A wet arm uses the hoon as a macro. We create a new type analysis
43+ path, which works as if we expanded the callee with the caller's
44+ context.
45+
46+_See [advanced types](/docs/hoon/hoon-expressions/advanced/)_.
47+
48+
49+
50+### Arvo
51+
52+The Urbit operating system and kernel. Arvo's state is a pure function of its
53+event log, and it serves as the Urbit event manager. It contains vanes, which are
54+kernel modules that perform essential system operations. Arvo itself can only
55+deal with one file at a time. For more, it relies on Ford, the build-system
56+vane.
57+
58+Arvo being purely functional means that the it is a function that is:
59+
60+`(state, event) → (state, effects)`
61+
62+Arvo coordinates and reloads vanes. It can be thought of as a traffic-director.
63+Any vane needs to go through Arvo before reaching another vane. Events and
64+their effects happen like so:
65+
66+`Unix event → vere (the virtual machine that runs Urbit) → Arvo → vane → Arvo`
67+
68+Arvo is located in `/home/sys/arvo.hoon` within your urbit.
69+
70+More in-depth information on Arvo can be found
71+[`here`](@/docs/arvo/_index.md).
72+
73+Below are Arvo modules, which are called "vanes".
74+
75+#### Ames
76+
77+ The networking vane. Ames handles all things UDP. Here live the protocols for
78+ discovering and interacting with other urbits. It’s also the name for the Urbit
79+ network itself. All communication is signed and encrypted.
80+
81+ Ames is located in `/home/sys/vane/ames.hoon` within your urbit.
82+
83+ More in-depth information on Ames can be found
84+ [`here`](@/docs/arvo/ames.md).
85+
86+#### Behn
87+
88+ The timing vane. Behn allows for applications to schedule events, which are
89+ managed in a simple priority queue. For example, Clay, the Urbit filesystem,
90+ uses Behn to keep track of time-specific file requests. Eyre, the Urbit web
91+ vane, uses Behn for timing-out HTTP sessions.
92+
93+ Behn is located in `/home/sys/vane/behn.hoon` within your urbit.
94+
95+#### Clay
96+
97+ The filesystem and typed revision-control vane. Think of Clay as a
98+ continuously synced git. It handles file-change events and maps them from Urbit
99+ to Unix and vice versa.
100+
101+ A common way to use it is to create a pier, a directory that exists in and is
102+ visible in Unix.
103+
104+ Clay is located at `/home/sys/vane/clay.hoon` within your urbit.
105+
106+ Basic information on using Clay can be found
107+ [`here`](@/operations.md). An in-depth explanation
108+ of the architecture can be found
109+ [`here`](@/docs/arvo/clay.md).
110+
111+#### Dill
112+
113+ The terminal-driver vane. You run your urbit in your Unix terminal, and
114+ Unix sends every event -- such as a keystroke or a change in the dimensions of
115+ the terminal window -- to be handled by Dill. Dill acts as an intermediary for
116+ anything that uses keyboard events. This is why there’s some input lag in
117+ Urbit’s command-line interface. (Optimization will come later!)
118+
119+ A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined
120+ as diagrammed below:
121+ ```
122+ Keystroke in Unix -> Vere (virtual machine) -> Arvo -> Dill -> the Dojo
123+ ```
124+
125+ Dill is located at `/home/sys/vane/dill.hoon` within your urbit.
126+
127+ More in-depth information on Dill can be found
128+ [`here`](@/docs/arvo/dill.md).
129+
130+#### Eyre
131+
132+ The web-server vane. Anything HTTP-related lives here. Unix sends HTTP messages
133+ though to Eyre, and Eyre produces HTTP messages in response.
134+
135+ In general, apps and vanes do not call Eyre; rather, Eyre calls apps and vanes.
136+ Eyre uses Ford and Gall to functionally publish pages and facilitate
137+ communication with apps.
138+
139+ Eyre is located at `/home/sys/vane/eyre.hoon` within your urbit.
140+
141+ More in-depth information on Eyre can be found
142+ [`here`](@/docs/arvo/eyre.md).
143+
144+#### Ford
145+
146+ The build-system vane. Ford is capable of sequencing generic asynchronous
147+ computations. Its uses include linking source files into programs, assembling
148+ live-updating websites, and performing file-type conversions.
149+
150+ Ford neither accepts Unix events nor produces Unix effects. It exists
151+ entirely for the benefit of Urbit applications and other vanes, in particular
152+ Gall.
153+
154+ Ford is located at `/home/sys/vane/ford.hoon` within your urbit.
155+
156+ More in-depth information on Ford can be found
157+ [`here`](@/docs/arvo/ford.md).
158+
159+#### Gall
160+
161+ The application-management vane. Userspace apps -- daemons, really -- are
162+ started, stopped, and sandboxed by Gall. Gall provides developers with a
163+ consistent interface for hooking their app up to the operating system. It allows
164+ applications and other vanes to send messages to applications and subscribe to
165+ data streams. Messages coming into Gall are routed to the intended application,
166+ and the response comes back along the same route. If the intended target is on
167+ another ship, Gall will route it, behind the scenes, through Ames to the other
168+ ship.
169+
170+ Gall is located at `/home/sys/vane/gall.hoon` within your urbit.
171+
172+ More in-depth information on Gall can be found
173+ [`here`](@/docs/arvo/gall.md).
174+
175+### atom
176+
177+An atom is any natural number, including zero. The atom is the most basic data
178+type in [Nock](#nock) and [Hoon](#hoon). A Hoon atom type describes a Nock
179+atom with two additional pieces of metadata: an [_aura_](#aura), and an
180+optional constant.
181+
182+An atom type is _warm_ or _cold_ based on whether the constant exists.
183+
184+
185+#### warm
186+
187+ If the constant is `~` (null), any atom is in the type.
188+
189+#### cold
190+
191+ If the constant is `[~ atom]`, its only legal value is `atom`.
192+
193+_See [basic types](@/docs/hoon/hoon-expressions/basic.md)_
194+
195+### aura
196+
197+An aura is a soft atom type. They appear as strings beginning with `@`. Auras
198+represent the structure of an atom, print format, or other semantics. Its
199+constraints on the value of an atom aren't enforced in any way.
200+
201+You can cast something to an aura, like a decimal, and get back its hexademical.
202+For example:
203+
204+```
205+ > =a `@`29
206+ > ^- @ux a
207+ 0x1d
208+```
209+
210+Auras are an advisory type system. You can go up or down, but not sideways in
211+the hierarchy. `@t` and `@` can each be cast to the other, but @t can’t be cast
212+to `@u`, for example, without first being cast to the empty aura `@`.
213+
214+For example
215+
216+```
217+ > ^- @ 'c' :: 'c' is of the aura @t
218+ 99
219+
220+ > ^- @u 'c'
221+ ! exit
222+```
223+
224+Here is a non-exhaustive list of auras:
225+
226+```
227+Aura Meaning Example Literal Syntax
228+-------------------------------------------------------------------------
229+@d date
230+ @da absolute date ~2018.5.14..22.31.46..1435
231+@n nil ~
232+@p phonemic string (ship name) ~sorreg-namtyv
233+@r IEEE floating-point
234+ @rd double precision (64 bits) .~6.02214085774e23
235+ @rh half precision (16 bits) .~~3.14
236+@s signed integer, sign-bit low
237+ @sb signed binary --0b11.1000
238+ @sd signed decimal --1.000.056
239+ @sx signed hexadecimal -0x5f5.e138
240+@t UTF-8 text (cord) 'howdy'
241+ @ta ASCII text (knot) ~.howdy
242+ @tas ASCII text symbol (term) %howdy
243+@u unsigned integer
244+ @ub unsigned binary 0b11.1000
245+ @ud unsigned decimal 1.000.056
246+ @ux unsigned hexadecimal 0x5f5.e138
247+```
248+
249+You can find the list of all auras [here](@/docs/hoon/hoon-expressions/rune/constants.md).
250+
251+### blocksize
252+
253+Blocksize is the power-of-two bitwidth of an atom. So, an atom with a blocksize
254+of `3` has a bitwidth of `2^3`, which is 8. A bitwidth of 8, in turn, can
255+represent `2^8` values, or 256.
256+
257+### cast
258+
259+To cast is to put a Hoon expression through the compiler’s type-checker to test
260+whether the expression is guaranteed to evaluate to a product that falls within
261+the desired type. If the expression is not guaranteed to behave in this way,
262+then the compiler will halt with a nest-fail crash. Proper Hoon code will
263+include a cast for the product type of each gate.
264+
265+The cast rune is `^-` (pronounced "ket-hep"). So, to cast to a list of atoms,
266+we write `^- (list @)`. The irregular form of that expression is ``(list @)``.
267+
268+### cell
269+
270+In Nock and Hoon, a _cell_ is an ordered pair of [nouns](#noun).
271+
272+Syntax: `[a b]`.
273+
274+Cells orient to the right; for example, the noun [2 6 14 15] is short for
275+[2 [6 [14 15]]].
276+
277+
278+### clam
279+
280+A clam is the use of a structure as a gate. Usually used to verify marks from
281+other urbits.
282+
283+```
284+ > ((list @t) [97 98 ~])
285+ <|a b|>
286+```
287+
288+### cord
289+
290+In Hoon, `cord` is an aura for representing atoms as strings. UTF-8,
291+least-significant bit first. Represented as the aura `@t`.
292+
293+```
294+ > `@t`478.560.413.032
295+ 'hello'
296+```
297+
298+### core
299+
300+A _core_ is a [cell](#nock-cell) of `[code data]`, where we call the
301+code head the _battery_ and the data tail the _payload_. All code-data
302+structures in normal languages (functions, objects, modules, etc.)
303+translate to cores in Hoon.
304+
305+#### battery
306+
307+ The code-containing head of a core.
308+
309+#### payload
310+
311+ The data-containing tail of a core.
312+
313+_See [basic types](@/docs/hoon/hoon-expressions/basic.md)._
314+
315+### Dojo
316+
317+The Dojo is the Urbit shell; the command line where you run programs,
318+expressions, and system commands. It’s a CLI that is encountered right when
319+an urbit is started for the first time. It is somewhat analogous to Bash, the
320+Unix terminal, and more analogous to a Hoon REPL.
321+
322+You’ll notice that many things can’t be written here; this is normal. The Dojo
323+enforces syntactical correctness right at the command line. Strings that can’t
324+be continued into a valid expression are automatically trimmed back to something
325+that can be. Some syntactically invalid expressions can be completed, but the
326+Dojo will prevent them from being entered as a command. You can play around
327+with this functionality learn what syntax is kosher.
328+
329+### desk
330+
331+A desk is independently revision-controlled branch of urbit filesystem.
332+
333+_See [filesystem](@/operations.md#filesystem) and [Clay](@/docs/arvo/clay.md)._
334+
335+### duct
336+
337+A duct is an Arvo-level call stack. At the beginning of every duct is a Unix
338+event, such as a keystroke, network packet, timer event, or file change.
339+
340+A duct is a `list` of `wire`s. A wire is itself a `list` of `knot`s. A `knot`
341+is, in turn, a knot.
342+
343+### face
344+
345+A _face_ is the Hoon analog to what is a variable name in most other
346+programming languages. Faces are metadata labels for legs, allowing us to
347+address parts. Because there is no metadata in Nock, faces cannot exist in Nock.
348+
349+```
350+ > a=2
351+ a=2
352+```
353+
354+In the above example, `a` is the face and `2` is the value.
355+
356+Hoon has no scope or symbol-table; there is only the subject. To "declare" a
357+"variable" is to construct a new subject: `[name=value old-subject]`.
358+
359+_See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_.
360+
361+
362+### flag
363+
364+A `flag` is Hoon's version of a boolean. `0` (`%.y`) is _yes_, `1` (`%.n`) is
365+_no_.
366+
367+### gate
368+
369+A _gate_ is a [core](#core) with one [arm](#arm) -- Hoon's closest
370+analog to a function. To call a gate on an argument, replace the sample
371+(at [tree address](@/docs/hoon/hoon-expressions/limb/limb.md) `+6`
372+in the core) with the argument, and then compute the arm.
373+
374+The payload of a gate has a shape of `[sample context]`.
375+
376+#### sample
377+
378+ The argument tuple.
379+
380+#### context
381+
382+ The subject in which the gate was defined.
383+
384+_See [basic types](@/docs/hoon/hoon-expressions/basic.md),
385+[`%-` ("cenhep")](@/docs/hoon/hoon-expressions/rune/cen.md#cenhep) (the
386+[rune](#rune) for calling a `gate`)._
387+
388+### generator
389+
390+A _generator_ is like a limited Hoon script: it’s a shell command that produces
391+a value before disappearing. Generators take an input [noun](#noun) (a value)
392+and produce an output `noun` by performing calculations on its arguments,
393+prompting for input, or making HTTP requests.
394+
395+You need a `bar` rune like `|=` in your generator, because a generator is
396+essentially a function that you’re calling.
397+
398+Generators, unlike [apps](#application), hold no state. They are pure,
399+stateless functions, and they cannot send [moves](#move). Because of this,
400+generators are have a more narrow use than apps. Among the non-trivial uses of
401+a a generator is moving data into apps -- they’re the backbone of Urbit’s
402+information pipeline.
403+
404+Generators are run from the `/gen` directory of your current desk. For example,
405+to run a generator named `whatever.hoon`, you would type `> +whatever` in the
406+[Dojo](@/operations.md#using-the-shell).
407+
408+### glyph
409+
410+A _glyph_ is a single, non-alphanumeric ASCII character. Each glyph has its own
411+monosyllabic name, which allows the efficient communication of Hoon-related
412+information in speech. [`Runes`](#rune) are composed of two glyphs.
413+Below is a complete list of glyphs with their associated pronunciations.
414+
415+```
416+ace [1 space] gal < pal (
417+bar | gap [>1 space, nl] par )
418+bas \ gar > sel [
419+buc $ hax # mic ;
420+cab _ hep - ser ]
421+cen % kel { sig ~
422+col : ker } soq '
423+com , ket ^ tar *
424+doq " lus + tic `
425+dot . pam & tis =
426+fas / pat @ wut ?
427+zap !
428+```
429+
430+### Hall
431+
432+_Hall_ is the Urbit communication back-end. It’s a messaging bus that can work
433+with clients of all sorts. [`:talk`](#talk), the built-in chat client, is one
434+such app that uses Hall.
435+
436+_More information on Hall can be found [here](@/docs/arvo/hall.md)._
437+
438+#### circle
439+
440+ A circle is the “audience” of your messages -- who can receive them. It can be
441+ thought of as a chat channel, but this is a little too narrow. More
442+ specifically, it’s a named collection of messages created by and hosted on a
443+ ship’s Hall, usually represented as `~ship-name/circle-name`. On Talk,
444+ Urbit’s built-in chat front-end, the first circle that you will likely
445+ encounter is `~dopzod/urbit-help`.
446+
447+### Hood
448+
449+_Hood_ orchestrates many of the Urbit initialization systems necessary
450+for boot.
451+
452+### Hoon
453+
454+Hoon is a strict, higher-order typed functional language that compiles itself
455+to Nock.
456+
457+The Hoon source file is located in `/home/sys/hoon.hoon` within your urbit.
458+
459+_More information can be found in the [hoon](@/docs/hoon/_index.md) section._
460+
461+#### Mint
462+
463+ _Mint_ is the Hoon compiler function. Mint takes the subject type and the
464+ expression source (a [hoon](#a-hoon), for example) and produces the product
465+ type and nock formula. So [type hoon] is mapped to [type nock].
466+
467+### hoon
468+
469+A _hoon_ (lowercase) is the result of parsing a Hoon source expression into an
470+AST node. These AST nodes are nouns, like all other Hoon data. Because every
471+Hoon program is, in its entirety, a single expression of Hoon, the result of
472+parsing the whole thing into an AST is a single `hoon`.
473+
474+A hoon is a tagged union of the form `[%tag data]`, where the tag
475+is a constant such as `%brts` (from the source [rune](#rune) `|=`,
476+i.e. "bartis"), and is matched up with the appropriate type of data
477+(often more `hoon`s, from source subexpressions). For example, the
478+expression `:-(2 17)`, once parsed into an AST, becomes the following:
479+
480+```
481+[%clhp p=[%sand p=%ud q=2] q=[%sand p=%ud q=17]]
482+```
483+
484+The `%clhp` is produced from the rune `:-` (i.e. "colhep"). The 2 and
485+17 have each been parsed as `%sand`-tagged hoons, which represent
486+atoms (in this case each with an aura of `%ud`, i.e. unsigned
487+decimal).
488+
489+To parse Hoon source into a hoon AST, use `ream` on a `cord`
490+containing Hoon source. Try the following in [Dojo](@/operations.md#using-the-shell):
491+
492+```
493+(ream ':+(12 7 %a)')
494+```
495+
496+The result should be:
497+
498+```
499+[%clls p=[%sand p=%ud q=12] q=[%sand p=%ud q=7] r=[%rock p=%tas q=97]]
500+```
501+
502+See [expression reference](@/docs/hoon/hoon-expressions/rune/_index.md) for the full list of hoons.
503+
504+### irregular form
505+
506+Irregular forms are alternative ways of writing Hoon expressions, alternatives
507+to the digraphic runes such as `:~`. Irregular forms are usually more compact
508+than regular forms.=
509+
510+_See [irregular forms](@/docs/hoon/hoon-expressions/irregular.md)._
511+
512+### jet
513+
514+A _jet_ is a piece of C code that have equivalent products to a piece of Hoon or
515+Nock code. They are used for performance reasons; jets are meant to be faster
516+than the code that they are substituting for.
517+
518+Jets are necessary for mathematics, performance-wise, because Nock handles it
519+so inefficiently. Nock, for example, can’t decrement (reduce a number by one)
520+except by starting building a loop that starts from zero and increments to a
521+number just below.
522+
523+_See [API overview](@/docs/vere/api.md)._
524+
525+### lark
526+
527+A lark is an expression that returns a [limb](#limb) at the specified
528+address in a cell. Using `-` by itself returns the head of the subject, and
529+using `+` by itself returns the tail:
530+
531+```
532+> -:[[4 5] [6 [14 15]]]
533+[4 5]
534+
535+> +:[[4 5] [6 [14 15]]]
536+[6 14 15]
537+```
538+
539+You can combine `+` or `-` with either of `>` or `<` to get a more specific limb
540+of the subject. `-<` returns the head of the head; `->` returns the tail of the
541+head; `+<` returns the head of the tail; and `+>` returns the tail of the tail.
542+By alternating the `+`/`-` symbols with `<`/`>` symbols, you can go as deep as
543+you desire.
544+
545+```
546+> +>-:[[4 5] [6 [14 15]]]
547+14
548+
549+> +>+:[[4 5] [6 [14 15]]]
550+15
551+```
552+
553+### limb
554+
555+A _limb_ is an attribute or variable reference. A limb is an [arm](#arm) or a
556+[leg](#leg).
557+
558+To resolve a _limb_ named "foo", the subject is searched depth-first,
559+head-first for either a face named "foo" or a core with an arm of
560+"foo". If a face is found, the result is a leg, if a core is
561+found, the result is the product of the arm.
562+
563+#### leg
564+
565+ a subexpression, or subtree of the
566+ [subject](#nock-subject).
567+
568+#### wing
569+
570+ a search path into the subject, composed of
571+ limbs. Search occurs from right to left (`a.b` means `b` within `a`).
572+
573+_See [Limbs and wings](@/docs/hoon/hoon-expressions/limb/_index.md)_
574+
575+### move
576+
577+A move is the [Arvo](#arvo) equivalent of a syscall.
578+
579+### noun
580+
581+In [Nock](#nock) and [Hoon](#hoon), a _noun_ is an atom or a cell.
582+
583+### Nock
584+
585+Nock is a Turing-complete, non-lambda combinator interpreter. It's
586+Urbit's low-level programming language. Nock is functional and typeless.
587+
588+#### noun
589+
590+ an _atom_ or a _cell_.
591+
592+#### atom
593+
594+ any natural number, including zero.
595+
596+#### cell
597+
598+ any ordered pair of nouns.
599+
600+
601+#### subject
602+
603+ a noun - the data against which a _formula_ is evaluated.
604+
605+#### formula
606+
607+ a noun - a function at the nock level.
608+
609+#### product
610+
611+ a noun - the result of evaluating a formula against a subject.
612+
613+_See the [Nock definition](@/docs/nock/definition.md)._
614+
615+### mark
616+
617+A _mark_ is Urbit's version of a MIME type, if a MIME type was an
618+executable specification. The mark is just a label that's used as a path
619+to a local source file in the Arvo filesystem. This source file defines
620+a core that can mold untrusted data, diff and patch, convert to other
621+marks, etc.
622+
623+If this sounds like magic, it isn't quite magic. There's no way
624+for different urbits to make sure they mean the same thing by the
625+same mark. However, when incompatibility happens, marks ensure
626+that we at least handle the situation in a predictable way.
627+
628+#### metal
629+
630+Every core has a _metal_ which defines its variance model (ie, the
631+properties of the type of a compatible core). The default is `gold`
632+(invariant).
633+
634+- `gold`: _invariant_
635+- `lead`: _bivariant_
636+- `zinc`: _covariant_
637+- `iron`: _contravariant_
638+
639+_See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_.
640+
641+### ship
642+
643+An Urbit _ship_ is: a cryptographic title on a _will_ signed by private key; a
644+human-memorable name; and a packet-routing address. Ships are classed by the
645+number of bits in their address:
646+
647+```
648+ Size Name Parent Object Example
649+ ----- ------ ------ ------ -------
650+ 2^8 galaxy ~ supernode ~zod
651+ 2^16 star galaxy supernode ~dozbud
652+ 2^32 planet star user ~tasfyn-partyv
653+ 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
654+ 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
655+```
656+
657+Any ship can be called an _urbit_. The lowercase "u" distinguishes it from Urbit
658+the software stack and Urbit the network.
659+
660+_You can find a longer-form summary [here.](https://urbit.org/posts/essays/the-urbit-address-space/)._
661+
662+An Urbit identity is a string like `~firbyr-napbes`. It means nothing,
663+but it's easy to remember and say out loud. `~firbyr-napbes` is actually
664+just a 32-bit number (`3.237.967.392`, to be exact), like an IP address,
665+that we turn into a human-memorable string. The full name of this string
666+can be viewed by typing `our` in the Dojo, Urbit's shell. This is useful
667+when running a ship with a longer name, such as a _moon_ or a _comet_.
668+
669+Technically, an urbit is a secure digital identity that you own and
670+control with a cryptographic key, like a Bitcoin wallet. As in Bitcoin,
671+the supply of urbits is mathematically limited. This keeps the network
672+friendly, by making spam and abuse expensive.
673+
674+An urbit name is just a number; smaller numbers make shorter names.
675+Shorter names are easier to remember, so they're more valuable. So
676+urbits are classified by the number of bits in their name. (A ship name
677+is just a scrambled base-256 representation of the number.)
678+
679+A 32-bit urbit (like `~firbyr-napbes`) is called a _planet._ A 16-bit
680+urbit (like `~pollev)` is a _star._ An 8-bit ship (like `~mun`) is a
681+_galaxy._ A planet is an identity for an independent, adult human. Stars
682+and galaxies are network infrastructure.
683+
684+Each planet or star is launched by its _parent,_ the star or galaxy
685+whose number is its bottom half. So the planet `~firbyr-napbes`,
686+`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
687+`48.879`, whose parent is `~mun`, `0xef`, `239`. The galaxy at the address of
688+`0` is `~zod`.
689+
690+#### pier
691+
692+ A ship's _pier_ is its Unix directory. For planets, the name of the pier is
693+ usually the planet name.
694+
695+### structure
696+
697+A _structure_ is an idempotent [gate](#gate) (function) that constructs and
698+validates types in Hoon.
699+
700+An example: Arvo [marks](#mark) use Hoon's type system via structures to
701+validate untrusted network data.
702+
703+Here's some common structure terminology:
704+
705+#### bunt
706+
707+ A bunt is the default value of a [structure](#structure). It's also a verb;
708+ to _bunt_ a structure is to produce the bunt of that structure. For example,
709+ bunting `@` results in `0`, and bunting `@t` results in `''`. Bunting is
710+ performed with `*` followed by the structure in question:
711+
712+ ```
713+ > *@
714+ 0
715+ > *@t
716+ ''
717+ ```
718+
719+#### icon: The type of the mold's range
720+
721+_See [mold hoons](/docs/hoon/hoon-expressions/rune/buc/)._
722+
723+### rune
724+
725+A Hoon _rune_ is a pair of ASCII symbols used to begin a
726+[Hoon expression](#a-hoon).
727+
728+For example, the rune [`?:`](@/docs/hoon/hoon-expressions/rune/wut.md#wutcol) is
729+Hoon's most common conditional, a branch on a boolean test. The first
730+symbol in a rune represents a family of related runes. For example, the
731+[`?` family](@/docs/hoon/hoon-expressions/rune/wut.md) are all conditionals.
732+
733+The result of parsing a Hoon source expression—the rune, followed
734+by its respective children—into an AST node is simply called
735+a [`hoon`](#a-hoon).
736+
737+Runes have two syntactic forms, _tall_ and _flat_:
738+
739+#### tall
740+
741+ multiple lines, no parentheses, two or more spaces between tokens
742+
743+ Example:
744+
745+ ```
746+ > %+ add 2 2
747+ 4
748+ ```
749+
750+#### flat
751+
752+ one line, parentheses, one space between tokens
753+
754+ Example:
755+ ```
756+ > %+(add 2 2) :: regular flat form
757+ 4
758+
759+ > (add 2 2) :: irregular flat form
760+ 4
761+ ```
762+
763+Tall hoons can contain flat hoons, but not vice versa. All irregular
764+forms are flat.
765+
766+_See [hoon concept](#a-hoon),
767+[expressions](@/docs/hoon/hoon-expressions/rune/_index.md).
768+
769+### Sail
770+
771+_Sail_ is the Hoon markup language for XML.
772+
773+### scry
774+
775+To _scry_ means to request data from the Arvo namespace and bring it
776+to userspace.
777+
778+_See [.^ (dot-ket)](@/docs/hoon/hoon-expressions/rune/dot.md#dotket)._
779+
780+### slot
781+
782+`slot` is the name for Hoon's tree-addressing scheme.
783+
784+Every cell has a head and a tail, each of which may be either an atom or
785+a cell. Therefore every noun is a binary tree. `+1` or `.` resolves to
786+the whole cell (technically this would work against an atom as well).
787+The head of `+n` is `+2n`, the tail is `+(2n+1)`.
788+
789+`+7` is a special address for gates, because the position is defined
790+(by convention) as the context of a gate and of all cores.
791+
792+### talk
793+
794+_Talk_ is Urbit's built-in chat app. It’s one example of an app that can be
795+built on top of Hall, the Urbit back-end messaging system.
796+
797+_See [Messaging](@/operations.md#messaging). for more information._
798+
799+### type
800+
801+A Hoon _type_ defines a set (finite or infinite) of nouns and ascribes
802+some semantics to it. There is no direct syntax for defining
803+types; they are always defined by inference (i.e., by
804+[`mint`](#mint)), usually using a constructor ([structure](#structure)).
805+
806+All types are assembled out of base types defined in `++type`.
807+(Look up `++ type` in hoon.hoon for examples.) When the compiler
808+does type-inference on a program, it assembles complex types out
809+of the simpler built-in types.
810+
811+#### nest
812+
813+ `nest` is an internal Hoon function on two types which performs a type
814+ compatibility test. `nest` produces yes if the
815+ set of nouns in the second type is provably a subset of the first.
816+ If `nest` produces no, the Hoon programmer will receive a `nest-fail`
817+ error. This is one of the most commons errors in Hoon programming.
818+
819+ _See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_ and [troubleshooting](@/docs/arvo/ship-troubleshooting.md).
820+
821+
822+### Unit
823+
824+Hoon's equivalent of a nullable pointer or a Haskell Maybe. If `q` is `~`,
825+null, the type is _warm_; any atom is in the type. If `q` is `[~ x]`, where
826+`x` is any atom, the type is _cold_; its only legal value is the constant `x`.
827+
828+### Vane
829+
830+A _vane_ is an [Arvo](#arvo) module. Each Vane is a single file because Arvo
831+cannot, on its own, deal with programs that are split between multiple files.
832+Some vanes can do this, however.
833+
834+### Vere (pronounced “vair”)
835+
836+The runtime system, written in C, that implements [Nock](#nock). All
837+It’s written in C. Vere-level errors are prepended with as `bail:`.
838+
839+Vere is a virtual machine: it pretends to be hardware, and is the single point
840+of contact between your Urbit and the rest of your system. But more than that,
841+Vere handles the Urbit event log and handles jets. It’s also contains the i/o
842+drivers for Urbit’s vanes, responsible for generating events from Unix and
843+applying effects to Unix.
844+
845+### Zuse
846+
847+_Zuse_ is a defined interface for vanes. It contains the part of the Hoon
848+standard library that is specific to Arvo functionality.
849+
850+Arvo is located in `/home/sys/zuse.hoon` within your urbit.