@@ -1,850 +0,0 @@
5−aliases = ["docs/reference/arvo-glossary/"]
8−Urbit is renowned for its exotic terminology. Here's a simple overview
9−from the strange words within.
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."
14−This glossary only covers terms the Arvo side of the project. You can find the
15−Azimuth glossary [here](../azimuth/glossary)
19−Also known as an “app,” an _application_ is a Hoon program that can hold state.
23−An _arm_ is a named, functionally-computed attribute of a [core](#core).
25−The [hoon](#a-hoon) of each arm is compiled to a Nock formula, with the
26−enclosing [core](#core) itself as the subject.
28−There are two kinds of arms: _dry_ and _wet_. Most arms are
33− normal, `++`, polymorphic by means of _variance_
35− For a dry arm, we ask: is the new payload compatible with the old
36− payload (against which the core was compiled)?
40− unusual, `+-`, polymorphic by means of _genericity_
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
46−_See [advanced types](/docs/hoon/hoon-expressions/advanced/)_.
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
58−Arvo being purely functional means that the it is a function that is:
60−`(state, event) → (state, effects)`
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:
66−`Unix event → vere (the virtual machine that runs Urbit) → Arvo → vane → Arvo`
68−Arvo is located in `/home/sys/arvo.hoon` within your urbit.
70−More in-depth information on Arvo can be found
71−[`here`](@/docs/arvo/_index.md).
73−Below are Arvo modules, which are called "vanes".
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.
81− Ames is located in `/home/sys/vane/ames.hoon` within your urbit.
83− More in-depth information on Ames can be found
84− [`here`](@/docs/arvo/ames.md).
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.
93− Behn is located in `/home/sys/vane/behn.hoon` within your urbit.
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.
101− A common way to use it is to create a pier, a directory that exists in and is
104− Clay is located at `/home/sys/vane/clay.hoon` within your urbit.
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).
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!)
119− A keyboard event's journey from Unix to Dojo, the Urbit shell, can be imagined
120− as diagrammed below:
122− Keystroke in Unix -> Vere (virtual machine) -> Arvo -> Dill -> the Dojo
125− Dill is located at `/home/sys/vane/dill.hoon` within your urbit.
127− More in-depth information on Dill can be found
128− [`here`](@/docs/arvo/dill.md).
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.
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.
139− Eyre is located at `/home/sys/vane/eyre.hoon` within your urbit.
141− More in-depth information on Eyre can be found
142− [`here`](@/docs/arvo/eyre.md).
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.
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
154− Ford is located at `/home/sys/vane/ford.hoon` within your urbit.
156− More in-depth information on Ford can be found
157− [`here`](@/docs/arvo/ford.md).
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
170− Gall is located at `/home/sys/vane/gall.hoon` within your urbit.
172− More in-depth information on Gall can be found
173− [`here`](@/docs/arvo/gall.md).
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
182−An atom type is _warm_ or _cold_ based on whether the constant exists.
187− If the constant is `~` (null), any atom is in the type.
191− If the constant is `[~ atom]`, its only legal value is `atom`.
193−_See [basic types](@/docs/hoon/hoon-expressions/basic.md)_
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.
201−You can cast something to an aura, like a decimal, and get back its hexademical.
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 `@`.
217− > ^- @ 'c' :: 'c' is of the aura @t
224−Here is a non-exhaustive list of auras:
227−Aura Meaning Example Literal Syntax
228−-------------------------------------------------------------------------
230− @da absolute date ~2018.5.14..22.31.46..1435
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
244− @ub unsigned binary 0b11.1000
245− @ud unsigned decimal 1.000.056
246− @ux unsigned hexadecimal 0x5f5.e138
249−You can find the list of all auras [here](@/docs/hoon/hoon-expressions/rune/constants.md).
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.
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.
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 @)``.
270−In Nock and Hoon, a _cell_ is an ordered pair of [nouns](#noun).
274−Cells orient to the right; for example, the noun [2 6 14 15] is short for
280−A clam is the use of a structure as a gate. Usually used to verify marks from
284− > ((list @t) [97 98 ~])
290−In Hoon, `cord` is an aura for representing atoms as strings. UTF-8,
291−least-significant bit first. Represented as the aura `@t`.
294− > `@t`478.560.413.032
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.
307− The code-containing head of a core.
311− The data-containing tail of a core.
313−_See [basic types](@/docs/hoon/hoon-expressions/basic.md)._
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.
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.
331−A desk is independently revision-controlled branch of urbit filesystem.
333−_See [filesystem](@/operations.md#filesystem) and [Clay](@/docs/arvo/clay.md)._
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.
340−A duct is a `list` of `wire`s. A wire is itself a `list` of `knot`s. A `knot`
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.
354−In the above example, `a` is the face and `2` is the value.
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]`.
359−_See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_.
364−A `flag` is Hoon's version of a boolean. `0` (`%.y`) is _yes_, `1` (`%.n`) is
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.
374−The payload of a gate has a shape of `[sample context]`.
382− The subject in which the gate was defined.
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`)._
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.
395−You need a `bar` rune like `|=` in your generator, because a generator is
396−essentially a function that you’re calling.
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.
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).
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.
416−ace [1 space] gal < pal (
417−bar | gap [>1 space, nl] par )
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.
436−_More information on Hall can be found [here](@/docs/arvo/hall.md)._
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`.
449−_Hood_ orchestrates many of the Urbit initialization systems necessary
454−Hoon is a strict, higher-order typed functional language that compiles itself
457−The Hoon source file is located in `/home/sys/hoon.hoon` within your urbit.
459−_More information can be found in the [hoon](@/docs/hoon/_index.md) section._
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].
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`.
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:
481−[%clhp p=[%sand p=%ud q=2] q=[%sand p=%ud q=17]]
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
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):
496−The result should be:
499−[%clls p=[%sand p=%ud q=12] q=[%sand p=%ud q=7] r=[%rock p=%tas q=97]]
502−See [expression reference](@/docs/hoon/hoon-expressions/rune/_index.md) for the full list of hoons.
506−Irregular forms are alternative ways of writing Hoon expressions, alternatives
507−to the digraphic runes such as `:~`. Irregular forms are usually more compact
510−_See [irregular forms](@/docs/hoon/hoon-expressions/irregular.md)._
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.
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
523−_See [API overview](@/docs/vere/api.md)._
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:
532−> -:[[4 5] [6 [14 15]]]
535−> +:[[4 5] [6 [14 15]]]
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
546−> +>-:[[4 5] [6 [14 15]]]
549−> +>+:[[4 5] [6 [14 15]]]
555−A _limb_ is an attribute or variable reference. A limb is an [arm](#arm) or a
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.
565− a subexpression, or subtree of the
566− [subject](#nock-subject).
570− a search path into the subject, composed of
571− limbs. Search occurs from right to left (`a.b` means `b` within `a`).
573−_See [Limbs and wings](@/docs/hoon/hoon-expressions/limb/_index.md)_
577−A move is the [Arvo](#arvo) equivalent of a syscall.
581−In [Nock](#nock) and [Hoon](#hoon), a _noun_ is an atom or a cell.
585−Nock is a Turing-complete, non-lambda combinator interpreter. It's
586−Urbit's low-level programming language. Nock is functional and typeless.
590− an _atom_ or a _cell_.
594− any natural number, including zero.
598− any ordered pair of nouns.
603− a noun - the data against which a _formula_ is evaluated.
607− a noun - a function at the nock level.
611− a noun - the result of evaluating a formula against a subject.
613−_See the [Nock definition](@/docs/nock/definition.md)._
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
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.
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`
634−- `gold`: _invariant_
635−- `lead`: _bivariant_
636−- `zinc`: _covariant_
637−- `iron`: _contravariant_
639−_See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_.
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:
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
657−Any ship can be called an _urbit_. The lowercase "u" distinguishes it from Urbit
658−the software stack and Urbit the network.
660−_You can find a longer-form summary [here.](https://urbit.org/posts/essays/the-urbit-address-space/)._
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_.
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.
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.)
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.
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
692− A ship's _pier_ is its Unix directory. For planets, the name of the pier is
693− usually the planet name.
697−A _structure_ is an idempotent [gate](#gate) (function) that constructs and
698−validates types in Hoon.
700−An example: Arvo [marks](#mark) use Hoon's type system via structures to
701−validate untrusted network data.
703−Here's some common structure terminology:
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:
719−#### icon: The type of the mold's range
721−_See [mold hoons](/docs/hoon/hoon-expressions/rune/buc/)._
725−A Hoon _rune_ is a pair of ASCII symbols used to begin a
726−[Hoon expression](#a-hoon).
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.
733−The result of parsing a Hoon source expression—the rune, followed
734−by its respective children—into an AST node is simply called
737−Runes have two syntactic forms, _tall_ and _flat_:
741− multiple lines, no parentheses, two or more spaces between tokens
752− one line, parentheses, one space between tokens
756− > %+(add 2 2) :: regular flat form
759− > (add 2 2) :: irregular flat form
763−Tall hoons can contain flat hoons, but not vice versa. All irregular
766−_See [hoon concept](#a-hoon),
767−[expressions](@/docs/hoon/hoon-expressions/rune/_index.md).
771−_Sail_ is the Hoon markup language for XML.
775−To _scry_ means to request data from the Arvo namespace and bring it
778−_See [.^ (dot-ket)](@/docs/hoon/hoon-expressions/rune/dot.md#dotket)._
782−`slot` is the name for Hoon's tree-addressing scheme.
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)`.
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.
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.
797−_See [Messaging](@/operations.md#messaging). for more information._
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)).
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.
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.
819− _See [advanced types](@/docs/hoon/hoon-expressions/advanced.md)_ and [troubleshooting](@/docs/arvo/ship-troubleshooting.md).
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`.
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.
834−### Vere (pronounced “vair”)
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:`.
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.
847−_Zuse_ is a defined interface for vanes. It contains the part of the Hoon
848−standard library that is specific to Arvo functionality.
850−Arvo is located in `/home/sys/zuse.hoon` within your urbit.