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