@@ -15,7 +15,7 @@ to create a new semantic level in which one can be absolutely precise."
18−An Urbit `ship` is a cryptographic title on a `will` signed by private
18+An Urbit *ship* is a cryptographic title on a *will* signed by private
19key, a human-memorable name, and a packet routing address. Ships are
19key, a human-memorable name, and a packet routing address. Ships are
20classed by the number of bits in their address:
20classed by the number of bits in their address:
@@ -27,7 +27,7 @@ classed by the number of bits in their address:
27 2^64 moon planet device ~sigsam-nimbot-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
28 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
30−Any ship can be called an `urbit`.
30+Any ship can be called an "urbit."
32> A summary [here](http://urbit.org/posts/address-space/).
32> A summary [here](http://urbit.org/posts/address-space/).
@@ -46,12 +46,12 @@ Shorter 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
46urbits are classified by the number of bits in their name. (A ship name
47is just a scrambled base-256 representation of the number.)
47is just a scrambled base-256 representation of the number.)
49−A 32-bit urbit (like `~firbyr-napbes`) is called a "planet." A 16-bit
49+A 32-bit urbit (like `~firbyr-napbes`) is called a *planet.* A 16-bit
50−urbit (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
50+urbit (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
51+*galaxy.* A planet is an identity for an independent, adult human. Stars
52and galaxies are network infrastructure.
52and galaxies are network infrastructure.
54−Each planet or star is launched by its "parent," the star or galaxy
54+Each planet or star is launched by its *parent,* the star or galaxy
55whose number is its bottom half. So the planet `~firbyr-napbes`,
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
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`
57`48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of `~mun`
@@ -61,14 +61,14 @@ and all galaxies is `~zod`, `0`.
62> Nock is a Turing-complete, non-lambda combinator interpreter.
62> Nock is a Turing-complete, non-lambda combinator interpreter.
64−- `noun`: an `atom` or a `cell`
64+- *noun*: an *atom* or a *cell*
65−- `atom`: any natural number
65+- *atom*: any natural number
66−- `cell`: any ordered pair of `noun`s
66+- *cell*: any ordered pair of nouns
67−- `subject`: a `noun` - the data against which a `formula` is
67+- *subject*: a noun - the data against which a `formula` is
69−- `formula`: a `noun` - a function at the Nock level
69+- *formula*: a noun - a function at the Nock level
70−- `product`: a `noun` - the result of evaluating a `formula` against a
70+- *product*: a noun - the result of evaluating a formula against a
73*See [Nock definition](../../nock/definition/).*
73*See [Nock definition](../../nock/definition/).*
@@ -77,49 +77,49 @@ and all galaxies is `~zod`, `0`.
77> Hoon is a strict, higher-order typed functional language that compiles
77> Hoon is a strict, higher-order typed functional language that compiles
78> itself to Nock.
78> itself to Nock.
80−###### `span`: an inferred type
80+###### span: an inferred type
82−A `span` defines a set (finite or infinite) of `noun`s and ascribes some
82+A *span* defines a set (finite or infinite) of nouns and ascribes some
83−semantics to it. There is no Hoon syntax for a `span`; it is always
83+semantics to it. There is no Hoon syntax for a span; it is always
84−produced as the inferred range of an expression (`twig`).
84+produced as the inferred range of an expression (*twig*).
86*See [basic types](../../hoon/basic/#-type-span-and-mold).*
86*See [basic types](../../hoon/basic/#-type-span-and-mold).*
88−###### `core`: a code-data `cell`
88+###### core: a code-data cell
90−The code (`battery`) is the head, the data (`payload`) is the tail. All
90+The code (*battery*) is the head, the data (*payload*) is the tail. All
91code-data structures in normal languages (functions, objects, modules,
91code-data structures in normal languages (functions, objects, modules,
92−etc) become `core`s in Hoon.
92+etc) become *core*s in Hoon.
94−- `battery`: the code of a `core`, a tree of `arm`s
94+- *battery*: the code of a core, a tree of *arms*
95−- `payload`: the data in a `core`
95+- *payload*: the data in a core
97*See [basic types](../../hoon/basic)*.
97*See [basic types](../../hoon/basic)*.
99−###### `arm`: a named, functionally-computed attribute of a `core`
99+###### arm: a named, functionally-computed attribute of a core
101−The `twig` of each `arm` is compiled to a Nock formula, with the
101+The *twig* of each arm is compiled to a Nock formula, with the
102enclosing `core` itself as the subject.
102enclosing `core` itself as the subject.
104−There are two kinds of `arm`s: `dry` and `wet`. Most arms are dry.
104+There are two kinds of arms: *dry* and *wet*. Most arms are dry.
106−- `dry`: normal, `++`, polymorphic by means of *variance*
106+- *dry*: normal, `++`, polymorphic by means of *variance*
108−For a `dry` `arm`, we ask, is the new `payload` compatible with the old
108+For a dry arm, we ask, is the new payload compatible with the old
109−`payload` (against which the `core` was compiled)?
109+payload (against which the core was compiled)?
111−- `wet`: unusual, `+-`, polymorphic by means of *genericity*
111+- *wet*: unusual, `+-`, polymorphic by means of *genericity*
113−A `wet` `arm` uses the `twig` as a macro. We create a new type analysis
113+A 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
114path, which works as if we expanded the callee with the caller's
117*See [advanced types](/hoon/advanced)*.
117*See [advanced types](/hoon/advanced)*.
119−###### `metal`: a variance model
119+###### metal a variance model
121−Every `core` has a `metal` which defines its *variance* model (ie, the
121+Every core has a *metal* which defines its variance model (ie, the
122−properties of the `span` of a compatible `core`). The default is `gold`
122+properties of the span of a compatible core). The default is `gold`
123(invariant).
123(invariant).
125- `gold`: *invariant*
125- `gold`: *invariant*
@@ -129,87 +129,88 @@ properties of the `span` of a compatible `core`). The default is `gold`
130*See [advanced types](/hoon/advanced)*.
130*See [advanced types](/hoon/advanced)*.
132−###### `gate`: a function/lambda/closure
132+###### gate: a function/lambda/closure
134−A `gate` is a `core` with one `arm`. To call a `gate` on an argument,
134+A *gate* is a core with one arm. To call a gate on an argument,
135−replace the `sample` (at tree address `6` in the `core`) with the
135+replace the sample (at [tree
136+address](../../hoon/twig/limb/limb/) `+6` in the core) with the
136−argument, and then compute the `arm`.
137+argument, and then compute the arm.
138−The `payload` of a `gate` has a shape of `{sample context}`.
139+The payload of a gate has a shape of `{sample context}`.
140−- `sample`: the argument tuple
141+- *sample*: the argument tuple
141−- `context`: the subject in which the `gate` was defined
142+- *context*: the subject in which the gate was defined
143*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span),
144*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span),
144[`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for
145[`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for
145calling a `gate`).*
146calling a `gate`).*
147−###### `mold`: a type constructor / validator
148+###### mold: a type constructor / validator
149−A mold is an idempotent `gate` (function), accepting any `noun`, and
150+A *mold* is an idempotent gate (function), accepting any noun, and
150−producing a range with a useful `span`.
151+producing a range with a useful span.
152−- `bunt`: the value a `mold` produces when normalizing its default
153+- *bunt*: the value a mold produces when normalizing its default
154−- `icon`: the `span` of the `mold`'s range
155+- *icon*: the span of the mold's range
156−*See [`mold` `twig`s](/hoon/twig/buc-mold/).*
157+*See [mold twigs](/hoon/twig/buc-mold/).*
158−###### `atom`
159+###### atom
160−A Hoon `atom` span describes a Nock `atom`, with two additional pieces
161+A Hoon *atom* span describes a Nock atom, with two additional pieces
161−of metadata: an `aura`, and an optional constant.
162+of metadata: an *aura*, and an optional constant.
163−An `atom` span is `warm` or `cold` based on whether the constant exists.
164+An 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+- *warm*: if the constant is `~` (null), any atom is in the span
166−- `cold`: if the constant is `[~ atom]`, its only legal value is
167+- *cold*: if the constant is `[~ atom]`, its only legal value is
169*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*
170*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*
171−###### `aura`: a soft `atom` type
172+###### *aura*: a soft atom type
173−`aura` is a name for an atom type. It represents the structure of an
174+*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,
175+atom in a string beginning with `@`. An aura may represent units,
175print format, or other semantics. Its constraints on the value of an
176print format, or other semantics. Its constraints on the value of an
176atom aren't enforced in any way.
177atom aren't enforced in any way.
178−Two `aura`s are compatible if one is a prefix of the other. You can
179+Two auras are compatible if one is a prefix of the other. You can
179−change any `aura` into any other `aura` by casting through the empty
180+change any aura into any other aura by casting through the empty
180−`aura`, `@`. The standard library has molds which alias many common
181+aura, `@`. The standard library has molds which alias many common
183Some common auras and their aliases:
184Some common auras and their aliases:
185−- `term` (`@tas`): a symbol - an atomic ASCII string which obeys
186+- *term* (`@tas`): a symbol - an atomic ASCII string which obeys
186 symbol rules: lowercase and digit only, infix hyphen ("kebab-case"),
187 symbol rules: lowercase and digit only, infix hyphen ("kebab-case"),
187 first character must be lowercase alphabetic.
188 first character must be lowercase alphabetic.
188−- `cord` (`@t`): UTF-8 text, least-significant-byte first
189+- *cord* (`@t`): UTF-8 text, least-significant-byte first
189−- `char` (`@tD`): a character, a single unicode byte (for multi-byte
190+- *char* (`@tD`): a character, a single unicode byte (for multi-byte
190 characters and codepoints, see `@c`)
191 characters and codepoints, see `@c`)
192*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*.
193*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*.
194−###### `twig`: a Hoon expression
195+###### twig: a Hoon expression
196−A `twig` is a Hoon expression. Specifically, `twig` is the mold for the
197+A *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.
198noun 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
200A 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
201pair of the two twigs, or a cell `{stem bulb}`, where `stem` is an
201atomic symbol.
202atomic symbol.
203−- `stem`: an atomic symbol (`@tas`) - the name of a `twig`.
204+- *stem*: an atomic symbol (`@tas`) - the name of a twig.
204−- `bulb`: The `mold` of the `twig`'s contents.
205+- *bulb*: The mold of the twig's contents.
206−Most `twig`s have a *regular form*, beginning with a `sigil` which is
207+Most twigs have a *regular form*, beginning with a *sigil* which is
207−either a `keyword` or a `rune`. Some `twig`s also have a syntactic
208+either a *keyword* or a *rune*. Some twigs also have a syntactic
208*irregular form*; a few have *only* an *irregular form*.
209*irregular form*; a few have *only* an *irregular form*.
210−- `sigil`: a `keyword` or `rune` used to begin a `twig`
211+- *sigil*: a *keyword* or *rune* used to begin a twig
211−- `keyword`: the value of a stem, prefixed with `:`.
212+- *keyword*: the value of a stem, prefixed with `:`.
212−- `rune`: a pair of ASCII symbols used to begin a `twig`.
213+- *rune*: a pair of ASCII symbols used to begin a twig.
214For example, the stem `%if` becomes the keyword
215For example, the stem `%if` becomes the keyword
215[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`. The first
216[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`. The first
@@ -222,47 +223,54 @@ easier.
223A regular twig has two syntactic forms, *tall* and *flat*:
224A regular twig has two syntactic forms, *tall* and *flat*:
225−- `tall`: multiple lines, no parentheses, two or more spaces between
226+- *tall*: multiple lines, no parentheses, two or more spaces between
227−- `flat`: one line, parentheses, one space between tokens
228+- *flat*: one line, parentheses, one space between tokens
229−`tall` twigs can contain `flat` ones, but not vice versa. All irregular
230+Tall twigs can contain flat ones, but not vice versa. All irregular
230−forms are `flat`.
231+forms are flat.
232−*See [`twig` concept](../../hoon/concepts/#-twig-expression),
233+*See [twig concept](../../hoon/concepts/#-twig-expression),
233[expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
234[expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
235−###### `limb`: attribute or variable reference
236+###### limb: attribute or variable reference
237−To resolve a `limb` named "foo", the `subject` is searched depth-first,
238+To resolve a *limb* named "foo", the subject is searched depth-first,
238−head-first for either a `face` named "foo" or a `core` with an `arm` of
239+head-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
240+"foo". If a face is found, the result is a leg, if a core is
240−found, the result is the `product` of the `arm`.
241+found, the result is the product of the arm.
242−- `leg`: a subexpression, or subtree of the `subject`.
243+- *leg*: a subexpression, or subtree of the subject.
243−- `wing`: a list of `limb`s, searched from right to left (`a.b` means
244+- *wing*: a list of limbs, searched from right to left (`a.b` means
244 `b` within `a`).
245 `b` within `a`).
246*See [Limbs and wings](../../hoon/twig/limb)*
247*See [Limbs and wings](../../hoon/twig/limb)*
248−###### `face`: a labeled subtree
249+###### slot: a tree addressing scheme
251+Every cell has a head and a tail, each of which may be either an atom or
252+a cell. Therefore every noun is a binary tree. `+1` or `.` resolves to
253+the whole cell (technically this would work against an atom as well).
254+The head of `+n` is `+2n`, the tail is `+(2n+1)`.
256+###### face: a labeled subtree
250−Hoon has no scope or symbol-table; there is only the `subject`. To
258+Hoon has no scope or symbol-table; there is only the subject. To
251−"declare" a "variable" is to construct a new `subject`:
259+"declare" a "variable" is to construct a new subject:
252`[name=value old-subject]`.
260`[name=value old-subject]`.
254−A `face` is a `span` that wraps a name (`@tas`) around another `span`.
262+A *face* is a span that wraps a name (`@tas`) around another span.
256*See [advanced types](../../hoon/advanced/#-face-aliases-and-bridges)*.
264*See [advanced types](../../hoon/advanced/#-face-aliases-and-bridges)*.
258−###### `nest`: type compatibility test
266+###### nest: type compatibility test
260−`nest` is an internal function on two spans, which produces yes if the
268+*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.
269set of nouns in the second span is provably a subset of the first.
263*See [advanced types](../../hoon/advanced/)*.
271*See [advanced types](../../hoon/advanced/)*.
265−###### `loobean`: a Hoon boolean
273+###### loobean: a Hoon boolean
267`0` (`%.y`) is *yes*, `1` (`%.n`) is *no*.
275`0` (`%.y`) is *yes*, `1` (`%.n`) is *no*.