@@ -1,849 +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 of 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/reference/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/tutorials/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/tutorials/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`](@/using/operations/using-your-ship.md). An in-depth explanation
108− of the architecture can be found
109− [`here`](@/docs/tutorials/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/tutorials/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/tutorials/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/tutorials/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/tutorials/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/reference/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/reference/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/reference/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 an independently revision-controlled branch of urbit filesystem.
333−_See [filesystem](@/using/operations/using-your-ship.md) and [Clay](@/docs/tutorials/arvo/clay.md)._
338−A duct is an Arvo-level call stack. At the beginning of every duct is a Unix
339−event, such as a keystroke, network packet, timer event, or file change.
341−A duct is a `list` of `wire`s. A wire is itself a `list` of `knot`s. A `knot`
346−A _face_ is the Hoon analog to what is a variable name in most other
347−programming languages. Faces are metadata labels for legs, allowing us to
348−address parts. Because there is no metadata in Nock, faces cannot exist in Nock.
355−In the above example, `a` is the face and `2` is the value.
357−Hoon has no scope or symbol-table; there is only the subject. To "declare" a
358−"variable" is to construct a new subject: `[name=value old-subject]`.
360−_See [advanced types](@/docs/reference/hoon-expressions/advanced.md)_.
365−A `flag` is Hoon's version of a boolean. `0` (`%.y`) is _yes_, `1` (`%.n`) is
370−A _gate_ is a [core](#core) with one [arm](#arm) -- Hoon's closest
371−analog to a function. To call a gate on an argument, replace the sample
372−(at [tree address](@/docs/reference/hoon-expressions/limb/limb.md) `+6`
373−in the core) with the argument, and then compute the arm.
375−The payload of a gate has a shape of `[sample context]`.
383− The subject in which the gate was defined.
385−_See [basic types](@/docs/reference/hoon-expressions/basic.md),
386−[`%-` ("cenhep")](@/docs/reference/hoon-expressions/rune/cen.md#cenhep) (the
387−[rune](#rune) for calling a `gate`)._
391−A _generator_ is like a limited Hoon script: it’s a shell command that produces
392−a value before disappearing. Generators take an input [noun](#noun) (a value)
393−and produce an output `noun` by performing calculations on its arguments,
394−prompting for input, or making HTTP requests.
396−You need a `bar` rune like `|=` in your generator, because a generator is
397−essentially a function that you’re calling.
399−Generators, unlike [apps](#application), hold no state. They are pure,
400−stateless functions, and they cannot send [moves](#move). Because of this,
401−generators are have a more narrow use than apps. Among the non-trivial uses of
402−a a generator is moving data into apps -- they’re the backbone of Urbit’s
403−information pipeline.
405−Generators are run from the `/gen` directory of your current desk. For example,
406−to run a generator named `whatever.hoon`, you would type `> +whatever` in the
407−[Dojo](@/using/operations/using-your-ship.md#using-the-shell).
411−A _glyph_ is a single, non-alphanumeric ASCII character. Each glyph has its own
412−monosyllabic name, which allows the efficient communication of Hoon-related
413−information in speech. [`Runes`](#rune) are composed of two glyphs.
414−Below is a complete list of glyphs with their associated pronunciations.
417−ace [1 space] gal < pal (
418−bar | gap [>1 space, nl] par )
433−_Hall_ is the Urbit communication back-end. It’s a messaging bus that can work
434−with clients of all sorts. [`:talk`](#talk), the built-in chat client, is one
435−such app that uses Hall.
439− A circle is the “audience” of your messages -- who can receive them. It can be
440− thought of as a chat channel, but this is a little too narrow. More
441− specifically, it’s a named collection of messages created by and hosted on a
442− ship’s Hall, usually represented as `~ship-name/circle-name`. On Talk,
443− Urbit’s built-in chat front-end, the first circle that you will likely
444− encounter is `~dopzod/urbit-help`.
448−_Hood_ orchestrates many of the Urbit initialization systems necessary
453−Hoon is a strict, higher-order typed functional language that compiles itself
456−The Hoon source file is located in `/home/sys/hoon.hoon` within your urbit.
458−_More information can be found in the [hoon](@/docs/tutorials/hoon/_index.md) section._
462− _Mint_ is the Hoon compiler function. Mint takes the subject type and the
463− expression source (a [hoon](#a-hoon), for example) and produces the product
464− type and nock formula. So [type hoon] is mapped to [type nock].
468−A _hoon_ (lowercase) is the result of parsing a Hoon source expression into an
469−AST node. These AST nodes are nouns, like all other Hoon data. Because every
470−Hoon program is, in its entirety, a single expression of Hoon, the result of
471−parsing the whole thing into an AST is a single `hoon`.
473−A hoon is a tagged union of the form `[%tag data]`, where the tag
474−is a constant such as `%brts` (from the source [rune](#rune) `|=`,
475−i.e. "bartis"), and is matched up with the appropriate type of data
476−(often more `hoon`s, from source subexpressions). For example, the
477−expression `:-(2 17)`, once parsed into an AST, becomes the following:
480−[%clhp p=[%sand p=%ud q=2] q=[%sand p=%ud q=17]]
483−The `%clhp` is produced from the rune `:-` (i.e. "colhep"). The 2 and
484−17 have each been parsed as `%sand`-tagged hoons, which represent
485−atoms (in this case each with an aura of `%ud`, i.e. unsigned
488−To parse Hoon source into a hoon AST, use `ream` on a `cord`
489−containing Hoon source. Try the following in [Dojo](@/using/operations/using-your-ship.md#using-the-shell):
495−The result should be:
498−[%clls p=[%sand p=%ud q=12] q=[%sand p=%ud q=7] r=[%rock p=%tas q=97]]
501−See [expression reference](@/docs/reference/hoon-expressions/rune/_index.md) for the full list of hoons.
505−Irregular forms are alternative ways of writing Hoon expressions, alternatives
506−to the digraphic runes such as `:~`. Irregular forms are usually more compact
509−_See [irregular forms](@/docs/reference/hoon-expressions/irregular.md)._
513−A _jet_ is a piece of C code that have equivalent products to a piece of Hoon or
514−Nock code. They are used for performance reasons; jets are meant to be faster
515−than the code that they are substituting for.
517−Jets are necessary for mathematics, performance-wise, because Nock handles it
518−so inefficiently. Nock, for example, can’t decrement (reduce a number by one)
519−except by starting building a loop that starts from zero and increments to a
522−_See [API overview](@/docs/tutorials/vere/api.md)._
526−A lark is an expression that returns a [limb](#limb) at the specified
527−address in a cell. Using `-` by itself returns the head of the subject, and
528−using `+` by itself returns the tail:
531−> -:[[4 5] [6 [14 15]]]
534−> +:[[4 5] [6 [14 15]]]
538−You can combine `+` or `-` with either of `>` or `<` to get a more specific limb
539−of the subject. `-<` returns the head of the head; `->` returns the tail of the
540−head; `+<` returns the head of the tail; and `+>` returns the tail of the tail.
541−By alternating the `+`/`-` symbols with `<`/`>` symbols, you can go as deep as
545−> +>-:[[4 5] [6 [14 15]]]
548−> +>+:[[4 5] [6 [14 15]]]
554−A _limb_ is an attribute or variable reference. A limb is an [arm](#arm) or a
557−To resolve a _limb_ named "foo", the subject is searched depth-first,
558−head-first for either a face named "foo" or a core with an arm of
559−"foo". If a face is found, the result is a leg, if a core is
560−found, the result is the product of the arm.
564− a subexpression, or subtree of the
565− [subject](#nock-subject).
569− a search path into the subject, composed of
570− limbs. Search occurs from right to left (`a.b` means `b` within `a`).
572−_See [Limbs and wings](@/docs/reference/hoon-expressions/limb/_index.md)_
576−A move is the [Arvo](#arvo) equivalent of a syscall.
580−In [Nock](#nock) and [Hoon](#hoon), a _noun_ is an atom or a cell.
584−Nock is a Turing-complete, non-lambda combinator interpreter. It's
585−Urbit's low-level programming language. Nock is functional and typeless.
589− an _atom_ or a _cell_.
593− any natural number, including zero.
597− any ordered pair of nouns.
602− a noun - the data against which a _formula_ is evaluated.
606− a noun - a function at the nock level.
610− a noun - the result of evaluating a formula against a subject.
612−_See the [Nock definition](@/docs/tutorials/nock/definition.md)._
616−A _mark_ is Urbit's version of a MIME type, if a MIME type was an
617−executable specification. The mark is just a label that's used as a path
618−to a local source file in the Arvo filesystem. This source file defines
619−a core that can mold untrusted data, diff and patch, convert to other
622−If this sounds like magic, it isn't quite magic. There's no way
623−for different urbits to make sure they mean the same thing by the
624−same mark. However, when incompatibility happens, marks ensure
625−that we at least handle the situation in a predictable way.
629−Every core has a _metal_ which defines its variance model (ie, the
630−properties of the type of a compatible core). The default is `gold`
633−- `gold`: _invariant_
634−- `lead`: _bivariant_
635−- `zinc`: _covariant_
636−- `iron`: _contravariant_
638−_See [advanced types](@/docs/reference/hoon-expressions/advanced.md)_.
642−An Urbit _ship_ is: a cryptographic title on a _will_ signed by private key; a
643−human-memorable name; and a packet-routing address. Ships are classed by the
644−number of bits in their address:
647− Size Name Parent Object Example
648− ----- ------ ------ ------ -------
649− 2^8 galaxy ~ supernode ~zod
650− 2^16 star galaxy supernode ~dozbud
651− 2^32 planet star user ~tasfyn-partyv
652− 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
653− 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
656−Any ship can be called an _urbit_. The lowercase "u" distinguishes it from Urbit
657−the software stack and Urbit the network.
659−_You can find a longer-form summary [here.](https://urbit.org/posts/essays/the-urbit-address-space/)._
661−An Urbit identity is a string like `~firbyr-napbes`. It means nothing,
662−but it's easy to remember and say out loud. `~firbyr-napbes` is actually
663−just a 32-bit number (`3.237.967.392`, to be exact), like an IP address,
664−that we turn into a human-memorable string. The full name of this string
665−can be viewed by typing `our` in the Dojo, Urbit's shell. This is useful
666−when running a ship with a longer name, such as a _moon_ or a _comet_.
668−Technically, an urbit is a secure digital identity that you own and
669−control with a cryptographic key, like a Bitcoin wallet. As in Bitcoin,
670−the supply of urbits is mathematically limited. This keeps the network
671−friendly, by making spam and abuse expensive.
673−An urbit name is just a number; smaller numbers make shorter names.
674−Shorter names are easier to remember, so they're more valuable. So
675−urbits are classified by the number of bits in their name. (A ship name
676−is just a scrambled base-256 representation of the number.)
678−A 32-bit urbit (like `~firbyr-napbes`) is called a _planet._ A 16-bit
679−urbit (like `~pollev)` is a _star._ An 8-bit ship (like `~mun`) is a
680−_galaxy._ A planet is an identity for an independent, adult human. Stars
681−and galaxies are network infrastructure.
683−Each planet or star is launched by its _parent,_ the star or galaxy
684−whose number is its bottom half. So the planet `~firbyr-napbes`,
685−`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
686−`48.879`, whose parent is `~mun`, `0xef`, `239`. The galaxy at the address of
691− A ship's _pier_ is its Unix directory. For planets, the name of the pier is
692− usually the planet name.
696−A _structure_ is an idempotent [gate](#gate) (function) that constructs and
697−validates types in Hoon.
699−An example: Arvo [marks](#mark) use Hoon's type system via structures to
700−validate untrusted network data.
702−Here's some common structure terminology:
706− A bunt is the default value of a [structure](#structure). It's also a verb;
707− to _bunt_ a structure is to produce the bunt of that structure. For example,
708− bunting `@` results in `0`, and bunting `@t` results in `''`. Bunting is
709− performed with `*` followed by the structure in question:
718−#### icon: The type of the mold's range
720−_See [mold hoons](/docs/reference/hoon-expressions/rune/buc/)._
724−A Hoon _rune_ is a pair of ASCII symbols used to begin a
725−[Hoon expression](#a-hoon).
727−For example, the rune [`?:`](@/docs/reference/hoon-expressions/rune/wut.md#wutcol) is
728−Hoon's most common conditional, a branch on a boolean test. The first
729−symbol in a rune represents a family of related runes. For example, the
730−[`?` family](@/docs/reference/hoon-expressions/rune/wut.md) are all conditionals.
732−The result of parsing a Hoon source expression—the rune, followed
733−by its respective children—into an AST node is simply called
736−Runes have two syntactic forms, _tall_ and _flat_:
740− multiple lines, no parentheses, two or more spaces between tokens
751− one line, parentheses, one space between tokens
755− > %+(add 2 2) :: regular flat form
758− > (add 2 2) :: irregular flat form
762−Tall hoons can contain flat hoons, but not vice versa. All irregular
765−_See [hoon concept](#a-hoon),
766−[expressions](@/docs/reference/hoon-expressions/rune/_index.md).
770−_Sail_ is the Hoon markup language for XML.
774−To _scry_ means to request data from the Arvo namespace and bring it
777−_See [.^ (dot-ket)](@/docs/reference/hoon-expressions/rune/dot.md#dotket)._
781−`slot` is the name for Hoon's tree-addressing scheme.
783−Every cell has a head and a tail, each of which may be either an atom or
784−a cell. Therefore every noun is a binary tree. `+1` or `.` resolves to
785−the whole cell (technically this would work against an atom as well).
786−The head of `+n` is `+2n`, the tail is `+(2n+1)`.
788−`+7` is a special address for gates, because the position is defined
789−(by convention) as the context of a gate and of all cores.
793−_Talk_ is Urbit's built-in chat app. It’s one example of an app that can be
794−built on top of Hall, the Urbit back-end messaging system.
796−_See [Messaging](@/using/operations/using-your-ship.md#messaging). for more information._
800−A Hoon _type_ defines a set (finite or infinite) of nouns and ascribes
801−some semantics to it. There is no direct syntax for defining
802−types; they are always defined by inference (i.e., by
803−[`mint`](#mint)), usually using a constructor ([structure](#structure)).
805−All types are assembled out of base types defined in `++type`.
806−(Look up `++ type` in hoon.hoon for examples.) When the compiler
807−does type-inference on a program, it assembles complex types out
808−of the simpler built-in types.
812− `nest` is an internal Hoon function on two types which performs a type
813− compatibility test. `nest` produces yes if the
814− set of nouns in the second type is provably a subset of the first.
815− If `nest` produces no, the Hoon programmer will receive a `nest-fail`
816− error. This is one of the most commons errors in Hoon programming.
818− _See [advanced types](@/docs/reference/hoon-expressions/advanced.md)_ and [troubleshooting](@/docs/tutorials/ship-troubleshooting.md).
823−Hoon's equivalent of a nullable pointer or a Haskell Maybe. If `q` is `~`,
824−null, the type is _warm_; any atom is in the type. If `q` is `[~ x]`, where
825−`x` is any atom, the type is _cold_; its only legal value is the constant `x`.
829−A _vane_ is an [Arvo](#arvo) module. Each Vane is a single file because Arvo
830−cannot, on its own, deal with programs that are split between multiple files.
831−Some vanes can do this, however.
833−### Vere (pronounced “vair”)
835−The runtime system, written in C, that implements [Nock](#nock). All
836−It’s written in C. Vere-level errors are prepended with as `bail:`.
838−Vere is a virtual machine: it pretends to be hardware, and is the single point
839−of contact between your Urbit and the rest of your system. But more than that,
840−Vere handles the Urbit event log and handles jets. It’s also contains the i/o
841−drivers for Urbit’s vanes, responsible for generating events from Unix and
842−applying effects to Unix.
846−_Zuse_ is a defined interface for vanes. It contains the part of the Hoon
847−standard library that is specific to Arvo functionality.
849−Arvo is located in `/home/sys/zuse.hoon` within your urbit.