![[Home]](http://www.bayleshanks.com/cartoonbayle.png)
This cheat sheet contains lists of 'Hoon' words and symbols and short descriptions of what they are or what they do. Note that we unabashedly map Hoon concepts to the closest corresponding concept in other programming languages, even if the concepts are not quite the same. For example, in biology, bird wings and bat wings are said to be analogous but not homologous, because they have similar function but they are not quite the same and indeed the common ancestor of birds and bats did not have wings. In this table, we map analogous concepts to each other even if they are not homologous; if bat wings and bird wings were here, we would map bat wings to bird wings. For example, we map 'gate' to 'function; see the section "Gates and lambda" from Hoon tutorial section 4 for more discussion of this.
Please note that i am writing this in the process of learning Hoon, and i don't understand most of what is written here yet, so there are probably many mistakes and misconceptions in this document.
Note: this is NOT meant to become a complete language reference; it is supposed to cover only those things that you need to know in order to understand the tutorial, and perhaps a few of the other most important language constructs.
add: addition
Arm: "A core formula is called an arm. An arm is almost like an object-oriented method, but not quite - a method would be an arm that produces a function on an argument. The arm is just a function of the core, ie, a computed attribute." "a computed expression". Note that an Arm expects to be called with the entire Core that it is a part of as its subject. Can also be thought of as consisting of both a symbol (the fieldname) and also a twig (the arm itself). If we Pull a Wing in a Core and the result is computed by a formula, then that result is an Arm; but if we Pull a Wing in a Core and the result is defined as a subtree of the Core, then that result is a Leg. [1] [2] [3] [4]
Ash: geometric polymorphism. 'dry'.
Atom: a natural number. Also a type stem %atom.
Axil: 'base' tile; see table Tiles.
Axis/Axes: a type of limb which is a fieldname/field selector. [5]
Bark: naming tile; see table Tiles.
Base: see table 'Tiles'
Battery: The head of a Core; code, containing one or more Formulas.
bean: short for Loobean (boolean)
Book: "a core which contains only code and constant data". "A core whose payload is either another core, or a constant (%cube)" Contrast to Cart [6] [7]
Bulb: The tail of a kelp. [8]
Bull: alias type [9]
bunt: a tile reduction. [10]
bush: pair/tag tile; see table Tiles. [11]
by: Maps container. "++by is the container for all the map arms. The contained arms inherit its sample, the map a." "Note: ++by is not used alone, but is used to call the arms it contains." [12]
Cart: "a core containing dynamic state". Contrast to Book. [13]
Cell: ordered pair of nouns. Syntax: [a b]. Groups to the right, so e.g. [2 6 14 15] is short for [2 [6 [14 15]]]. Also a type stem %cell.
clam: a tile reduction. A clam just produces a gate which executes a whip to the given tile (e.g. it produces a closure which remembers the tile you give it, as passes that to the whip reduction when it is called) [14]
Coil: todo. see http://doc.urbit.org/doc/hoon/tut/3/
Context: todo. Also indicated by '+>', or 'gras'. [15]
Core: a "core is just a cell whose tail is data (possibly containing other cores) and whose head is code (containing one or more formulas). The tail is the payload and the head is the battery...To activate a core, pick a formula out of the battery, and use the entire core (_not_ just the payload) as the subject." or "a core is a [code data] cell - [battery payload]. Essentially, an object. The battery, at the Nock level, is a tree of formulas, each of whose subject is the core itself.". " A core is a noun of the form [battery payload] where the battery is a tree of formulas, each invoked with the entire core as the subject, and the payload is any noun.". "There are three main ways we can talk about a core: its variance model, %gold, %iron, %zinc or %lead, %gold by default; the inference approach of each of its feet, %ash or %elm, informally dry or wet, dry or ash by default; and its payload pattern, which makes it a gate, reef, book, trap or tray. There are also several ways of using cores: you can pull, kick, slam or slug them." %core is also a type stem. [16] [17] [18]
Cord: string. syntax: 'this is a string'; 'to escape a \'quote\', use \'backslash\. [19]
cube: todo type stem. Related to constants.
cue: unmarshall
dec: decrement. [20]
Dry: geometric polymorphism. ash. [21]
Elm: generic polymorphism. 'wet'. [22]
f(x): f(x) (?where f and x are alphanumerics?) is the irregular form of %=(f x). [23]
Face: todo type stem. presumably short for 'interface'
Fern: plain selection tile; see table Tiles.
Fish: a tile reduction. [24]
Foot: todo. http://web.archive.org/web/20131005080850/http://www.urbit.org/2013/08/22/Chapter-5-types.html says that the formulas in a battery are called '%foot's, but i haven't seen that elsewhere yet. [25]
Fork: todo type stem.
Formula: In Nock, Nock instructions are generally cells of the form [subject formula]. "Intuitively, the formula is your function and the subject is its argument. We call them something different because Hoon, or any other high-level language built on Nock, will build its own function calling convention which does not map directly to *[subject formula]....Basically, the subject is your data and the formula is your code.". [26]
Frond: A case within a kelp. [27]
Gate: a core serving as a function. "A gate is a trap whose payload has the form [sample context], sample being dynamic data and context being anything." I think a Gate is of the form [formula payload] (contrast to a Core, which is [battery payload], where a Battery can be a structure with many Formulas), but i'm not sure. Syntax: ++gatename to indicate the gate named 'gatename'. todo. see also table 'Gate, parts of'. see also http://doc.urbit.org/doc/hoon/tut/4/ . "Every gate is a trap. Every gate is a tray." [28] [29]
gen: todo, i see this all over the place in the tutorial, but i don't know what it is. e.g. in http://doc.urbit.org/doc/hoon/tut/6/ in ++open. Is this just an internal variable name in the interpreter for the AST we are currently processing?
Geometric polymorphism: [30]
Glyph: A punctuation character. Hoon assigns non-standard names to them, see table "Glyphs (Hoon glyph names)", below.
Gold: polymorphism with variance: invariant. [31]
Gonad: todo, see http://doc.urbit.org/doc/hoon/tut/7/
Herb: function (custom) tile; see table Tiles.
Hold: %hold is the pseudolazy evaluation type stem. [32]
homo: homogenize the type of a list. [33]
Hoon: Language name. Synonym for rune. What else?
homo: homogenize. "homogenizes the type of a list, producing its sample noun unchanged" [34]
Icon: the type of a tile? [35]
Iron: polymorphism with variance: contravariant. [36]
jam: marshall
Kelp: tag selection tile; see table Tiles. The head of a kelp must be a leaf. The head of a kelp is called a stem, and the tail is called a bulb. Cases of a kelp are called fronds. [37]
Kick: "To pull %$ - the empty name - on a core is to kick it. To replace the sample with a in gate g then kick the gate, is to slam g with a." [38]
Lead: polymorphism with variance: bivariant. [39]
Leaf: constant atom tile; see table Tiles.
Leg: "part of a typed noun (a fragment, as in Nock /)". If we Pull a Wing in a Core and the result is computed by a formula, then that result is an Arm; but if we Pull a Wing in a Core and the result is defined as a subtree of the Core, then that result is a Leg. [40] [41]
Limb: Part of a Wing. "a name or axis (which of course applies to all nouns, not just cores) is a limb. A list of limbs is a wing." "Each limb in the wing can be either a tree address (like +3, meaning Nock’s /3) or a name (like foo).". See also "name resolution" in http://doc.urbit.org/doc/hoon/tut/2/ . [42] [43]
Line: see table 'Tiles'
Loobean: boolean (note that 1 is false and 0 is true). syntax: .y == & == 0, .n ==
| === 1. [44] |
map: todo. ++ map: "A map is a tree of [p=* q=*] cells where n is the node, and l and r are branches." [45]
Mint: within the Hoon interpreter, the function (gate) ++mint contains the semantics of Hoon. That is, ++mint maps [type twig] to [type nock]. ++mint is found within ++ut. [46]
mul: multiplication
Natural hoon: a hoon which is not synthetic, e.g. which is not defined in terms of other hoons. See table below.
Nest: ++nest is the predicate function isSuperTypeOf, e.g. (nest a b) tests whether a is a supertype of b. Convention: we write (nest sut ref), e.g. 'sut' is the purported supertype and ref is the purported subtype. Nest is conservative in that it only returns True if it can prove that sut is a supertype of ref; so sometimes it may return False when sut is a supertype of ref, but it can't determine that. [47]
Nil: An odor whose only value is '~' (the atom 0).
Noun: an atom or a cell
Odor: a second type system on top of the 'real' type system that tells you whether an Atom should be interpreted as an integer, a string, etc. See also http://doc.urbit.org/doc/hoon/tut/1/, http://doc.urbit.org/doc/hoon/lan/odor/. [48] [49]
Payload: The tail of a Core. Data, possibly containing other Cores. I think a Payload is usually of the form [sample context], but i'm not sure [50].
Play: ++play is like ++mint except ++play only does type inference. [51] [52]
Product: output of a twig
Pull: "To access a wing or limb in a core is to pull it." "To pull %$ - the empty name - on a core is to kick it. To replace the sample with a in gate g then kick the gate, is to slam g with a." "(The archaic usage of "call" for slam is discouraged, but common. Please at least do not use "call" to mean pull.)" [53]
put: todo (seen in http://doc.urbit.org/doc/hoon/tut/5/ but not in http://doc.urbit.org/doc/hoon/lib/ , todo, tell them)
Reed: atom/cell tile; see table Tiles. [54]
Reef: "A stack of cores in which the core below is the context of the one above, all the way down to the innermost core whose payload is a simple constant (for hoon.hoon, always the Kelvin version)". "Every reef is a book". "A book whose payload is either another reef, or a cube, is a reef. Effectively, a reef is an entirely constant core." [55] [56]