@@ -1,850 +0,0 @@
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.