@@ -1,126 +1,84 @@
4−In Hoon there are no reserved words. Instead, [`++twigs`]() (abstract
8+#### Hoon has no reserved words. Instead we use ASCII pairs we call runes.
5−syntax trees), are formed using a diagraph of two ASCII symbols, which
9+
6−is called a rune.
10+#### This is the complete index.
8−Runes are loosely divided into categories by their first character. To
12+<div class="book">
9−find documentation on each individual category, follow these links:
13+
12−
16+<list dataPath="docs/system/hoon/runes/bc" dataPreview="true" className="runes" childIsFragment="true"></list>
13−------------------------------------------------------------------------
17+
16−------------
20+## `| bar` (cores)
18−For example, the rune `?:`, pronounced "wutcol", is a rune that accepts
22+<list dataPath="docs/system/hoon/runes/br" dataPreview="true" className="runes" childIsFragment="true"></list>
19−three `++twig` expressions to form an "if-then-else statement," where
23+
20−`p` is the predicate, `q` is the "then" statement, and `r` is the "else"
24+---
22−
26+## `: col` (tuples)
23− [%wtcl p=twig q=twig r=twig]
27+
24−
28+<list dataPath="docs/system/hoon/runes/cl" dataPreview="true" className="runes" childIsFragment="true"></list>
25−In a program, it is used like so:
29+
28− |= [a=@ b=@]
32+## `% cen` (invocations)
30− ?: =(0 a) b
34+<list dataPath="docs/system/hoon/runes/cn" dataPreview="true" className="runes" childIsFragment="true"></list>
31− $(a (dec a), b +(b))
35+
33−Here the `=(0 a)` is `p`, the `b` is `q`, and the bottom line is the
37+
34−`r`.
38+## `. dot` (nock)
36−There are several benefits to using runes in lieu of reserved words.
40+<list dataPath="docs/system/hoon/runes/dt" dataPreview="true" className="runes" childIsFragment="true"></list>
37−First, it prevents the programmer from accidentally misusing a reserved
41+
38−word as a variable name, which also allows her to be sure that any word
42+---
39−in her progam is an identifier. Next, as the first ASCII symbol of the
43+
40−rune digraphs bears semantic significance, the programmer can look at
41−any rune and immediately have a basic, intuitive understanding as to
44−Next, rune syntax addresses several issues that arise in other
45−languages. First, it produces cleaner, less verbose code that
46−conveniently flows downward. To highlight the verbosity Hoon avoids by
47−implementing runes, here is the C equivalent of the `++add` source code
51− function(left-operand: atom, right-operand: atom)
53− if equals(0, left-operand) {
56− recurse(left-operand (decrement left-operand)),
57− right-operand (increment right-operand))
61−What is more, Hoon solves two problems that arise in functional
62−programming languages with very deep expression trees: first, the
63−collection of huge piles of closing parens at the end of large blocks;
64−and second, the fact that the depth of expression trees are thus bounded
65−by the width of the text box, as subexpressions tend to be indented.
66−Some languages solve the bracket-terminator problem by parsing
67−whitespace in order to use indentation to express tree depth:
74−While this is actually valid Hoon, it does not solve the width problem.
76−To address this problem, most Hoon `++twigs` have a short, fixed
77−fan-out. Thus, the parser does not need significant whitespace nor a
78−terminator to determine how many twigs follow a `?:`--it already knows
79−that the answer is three. A smart parser allows the Hoon programmer to
80−format her code using a [backstep pattern]() that allows her to descend
81−into a deep tree without losing right margin.
83−Lastly, but perhaps most significantly, code is meant to be seen, and
84−not read. Anyone who has even slight experience coding Hoon will tell
85−you that they can understand and connect with properly formatted Hoon
86−code on a deeper, more intuitive level that cannot be explained but must
87−be experienced. One doesn't read `++add`, she sees it.
92−While the second glyph in a rune means little or nothing, the first
93−defines a rough semantic category:
95− | bar Core construction
96− $ buc Tile construction
98− : col Tuple construction
99− . dot Nock operations
100− # hax Pretty printing
44+## `# hax` (printing)
101− ^ ket Type conversions
45+
102− ; sem Composers (and XML generators)
46+<list dataPath="docs/system/hoon/runes/hx" dataPreview="true" className="runes" childIsFragment="true"></list>
52+<list dataPath="docs/system/hoon/runes/kt" dataPreview="true" className="runes" childIsFragment="true"></list>
58+<list dataPath="docs/system/hoon/runes/sg" dataPreview="true" className="runes" childIsFragment="true"></list>
62+## `; sem` (composition)
64+<list dataPath="docs/system/hoon/runes/sm" dataPreview="true" className="runes" childIsFragment="true"></list>
104− = tis Subject modifiers
68+## `= tis` (subject modifiers)
105− ? wut Conditionals, booleans, and tests
69+
106− ! zap Special operations
70+<list dataPath="docs/system/hoon/runes/ts" dataPreview="true" className="runes" childIsFragment="true"></list>
108−As shown above, each glyph has its own monosyllabic name, designed to be
72+---
109−pronounced quickly in combination with another glyph to form a rune
73+
110−name. As languages are often read-aloud, this saves the programmer from
74+## `? wut` (conditional)
111−having to say "dollar sign, question mark"--"bucwut" is much more
75+
112−compact.
76+<list dataPath="docs/system/hoon/runes/wt" dataPreview="true" className="runes" childIsFragment="true"></list>
114−Irregular pronuncations
78+---
115−-----------------------
79+
116−
80+## `! zap` (special)
117−To avoid a few tongue-twisters, some runes have irregular pronunciations
81+
118−that should be noted:
82+<list dataPath="docs/system/hoon/runes/zp" dataPreview="true" className="runes" childIsFragment="true"></list>
120− -- hephep phep
84+</div>
125−Note: these runes are not members of any of the categories above, but
126−are mostly used to....