10Urbit is renowned for its exotic terminology. Here's a simple overview
11from the strange words in.
13As Dijkstra put it: "The purpose of abstraction is not to be vague, but
14to create a new semantic level in which one can be absolutely precise."
18An Urbit `ship` is a cryptographic title on a `will` signed by private
19key, a human-memorable name, and a packet routing address. Ships are
20classed by the number of bits in their address:
22 Size Name Parent Object Example
23 ----- ------ ------ ------ -------
24 2^8 galaxy ~ supernode ~zod
25 2^16 star galaxy supernode ~dozbud
26 2^32 planet star user ~tasfyn-partyv
27 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
28 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
30Any ship can be called an `urbit`.
32> A summary [here](http://urbit.org/posts/address-space/).
34An Urbit identity is a string like `~firbyr-napbes`. It means nothing,
35but it's easy to remember and say out loud. `~firbyr-napbes` is actually
36just a 32-bit number, like an IP address, that we turn into a
37human-memorable string.
39Technically, an urbit is a secure digital identity that you own and
40control with a cryptographic key, like a Bitcoin wallet. As in Bitcoin,
41the supply of urbits is mathematically limited. This keeps the network
42friendly, by making spam and abuse expensive.
44An urbit name is just a number; smaller numbers make shorter names.
45Shorter names are easier to remember, so they're more valuable. So
46urbits are classified by the number of bits in their name. (A ship name
47is just a scrambled base-256 representation of the number.)
49A 32-bit urbit (like `~firbyr-napbes`) is called a "planet." A 16-bit
50urbit (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
51"galaxy." A planet is an identity for an independent, adult human. Stars
52and galaxies are network infrastructure.
54Each planet or star is launched by its "parent," the star or galaxy
55whose number is its bottom half. So the planet `~firbyr-napbes`,
56`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
57`48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of `~mun`
58and all galaxies is `~zod`, `0`.
62> Nock is a Turing-complete, non-lambda combinator interpreter.
64- `noun`: an `atom` or a `cell`
65- `atom`: any natural number
66- `cell`: any ordered pair of `noun`s
67- `subject`: a `noun` - the data against which a `formula` is
69- `formula`: a `noun` - a function at the Nock level
70- `product`: a `noun` - the result of evaluating a `formula` against a
73*See [Nock definition](../../nock/definition/).*
77> Hoon is a strict, higher-order typed functional language that compiles
80###### `span`: an inferred type
82A `span` defines a set (finite or infinite) of `noun`s and ascribes some
83semantics to it. There is no Hoon syntax for a `span`; it is always
84produced as the inferred range of an expression (`twig`).
86*See [basic types](../../hoon/basic/#-type-span-and-mold).*
88###### `core`: a code-data `cell`
90The code (`battery`) is the head, the data (`payload`) is the tail. All
91code-data structures in normal languages (functions, objects, modules,
92etc) become `core`s in Hoon.
94- `battery`: the code of a `core`, a tree of `arm`s
95- `payload`: the data in a `core`
97*See [basic types](../../hoon/basic)*.
99###### `arm`: a named, functionally-computed attribute of a `core`
101The `twig` of each `arm` is compiled to a Nock formula, with the
102enclosing `core` itself as the subject.
104There are two kinds of `arm`s: `dry` and `wet`. Most arms are dry.
106- `dry`: normal, `++`, polymorphic by means of *variance*
108For a `dry` `arm`, we ask, is the new `payload` compatible with the old
109`payload` (against which the `core` was compiled)?
111- `wet`: unusual, `+-`, polymorphic by means of *genericity*
113A `wet` `arm` uses the `twig` as a macro. We create a new type analysis
114path, which works as if we expanded the callee with the caller's
117*See [advanced types](/hoon/advanced)*.
119###### `metal`: a variance model
121Every `core` has a `metal` which defines its *variance* model (ie, the
122properties of the `span` of a compatible `core`). The default is `gold`
128- `iron`: *contravariant*
130*See [advanced types](/hoon/advanced)*.
132###### `gate`: a function/lambda/closure
134A `gate` is a `core` with one `arm`. To call a `gate` on an argument,
135replace the `sample` (at tree address `6` in the `core`) with the
136argument, and then compute the `arm`.
138The `payload` of a `gate` has a shape of `{sample context}`.
140- `sample`: the argument tuple
141- `context`: the subject in which the `gate` was defined
143*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span),
144[`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for
147###### `mold`: a type constructor / validator
149A mold is an idempotent `gate` (function), accepting any `noun`, and
150producing a range with a useful `span`.
152- `bunt`: the value a `mold` produces when normalizing its default
154- `icon`: the `span` of the `mold`'s range
156*See [`mold` `twig`s](/hoon/twig/buc-mold/).*
160A Hoon `atom` span describes a Nock `atom`, with two additional pieces
161of metadata: an `aura`, and an optional constant.
163An `atom` span is `warm` or `cold` based on whether the constant exists.
165- `warm`: if the constant is `~` (null), any `atom` is in the `span`
166- `cold`: if the constant is `[~ atom]`, its only legal value is
169*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*
171###### `aura`: a soft `atom` type
173`aura` is a name for an atom type. It represents the structure of an
174`atom` in a string beginning with `@`. An aura may represent units,
175print format, or other semantics. Its constraints on the value of an
176atom aren't enforced in any way.
178Two `aura`s are compatible if one is a prefix of the other. You can
179change any `aura` into any other `aura` by casting through the empty
180`aura`, `@`. The standard library has molds which alias many common
183Some common auras and their aliases:
185- `term` (`@tas`): a symbol - an atomic ASCII string which obeys
186 symbol rules: lowercase and digit only, infix hyphen ("kebab-case"),
187 first character must be lowercase alphabetic.
188- `cord` (`@t`): UTF-8 text, least-significant-byte first
189- `char` (`@tD`): a character, a single unicode byte (for multi-byte
190 characters and codepoints, see `@c`)
192*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*.
194###### `twig`: a Hoon expression
196A `twig` is a Hoon expression. Specifically, `twig` is the mold for the
197noun that a Hoon source expression compiles to. A twig is always a cell.
199A twig has one of two forms: `{twig twig}`, which produces the ordered
200pair of the two twigs, or a cell `{stem bulb}`, where `stem` is an
203- `stem`: an atomic symbol (`@tas`) - the name of a `twig`.
204- `bulb`: The `mold` of the `twig`'s contents.
206Most `twig`s have a *regular form*, beginning with a `sigil` which is
207either a `keyword` or a `rune`. Some `twig`s also have a syntactic
208*irregular form*; a few have *only* an *irregular form*.
210- `sigil`: a `keyword` or `rune` used to begin a `twig`
211- `keyword`: the value of a stem, prefixed with `:`.
212- `rune`: a pair of ASCII symbols used to begin a `twig`.
214For example, the stem `%if` becomes the keyword
215[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`. The first
216symbol in a rune represents a family of related `twig`s. For example,
217the [`?` family](../../hoon/twig/wut-test/) are all conditionals.
219The keyword or rune forms are up to the programmer's choice. Most
220existing code uses runes, but the keyword form makes the learning path
223A regular twig has two syntactic forms, *tall* and *flat*:
225- `tall`: multiple lines, no parentheses, two or more spaces between
227- `flat`: one line, parentheses, one space between tokens
229`tall` twigs can contain `flat` ones, but not vice versa. All irregular
232*See [`twig` concept](../../hoon/concepts/#-twig-expression),
233[expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
235###### `limb`: attribute or variable reference
237To resolve a `limb` named "foo", the `subject` is searched depth-first,
238head-first for either a `face` named "foo" or a `core` with an `arm` of
239"foo". If a `face` is found, the result is a `leg`, if a `core` is
240found, the result is the `product` of the `arm`.
242- `leg`: a subexpression, or subtree of the `subject`.
243- `wing`: a list of `limb`s, searched from right to left (`a.b` means
246*See [Limbs and wings](../../hoon/twig/limb)*
248###### `face`: a labeled subtree
250Hoon has no scope or symbol-table; there is only the `subject`. To
251"declare" a "variable" is to construct a new `subject`:
252`[name=value old-subject]`.
254A `face` is a `span` that wraps a name (`@tas`) around another `span`.
256*See [advanced types](../../hoon/advanced/#-face-aliases-and-bridges)*.
258###### `nest`: type compatibility test
260`nest` is an internal function on two spans, which produces yes if the
261set of nouns in the second span is provably a subset of the first.
263*See [advanced types](../../hoon/advanced/)*.
265###### `loobean`: a Hoon boolean
267`0` (`%.y`) is *yes*, `1` (`%.n`) is *no*.
269> Why? It's fresh, it's different, it's new. And it's annoying. And it
270> keeps you on your toes. And it's also just intuitively right.
keysesc to close
- j k
- move down, up
- enter
- open
- esc
- back, or up a level
- 1 2 3 4
- readme, files, commits, refs
- /
- filter
- y
- copy the clone command
- c
- compare the chosen commit with another (or shift-click both)
- ?
- show or hide this list