@@ -1,116 +0,0 @@
8−For example, the rune `?:`, pronounced "wutcol", is a rune that accepts
9−three `++twig` expressions to form an "if-then-else statement," where
10−`p` is the predicate, `q` is the "then" statement, and `r` is the "else"
13− [%wtcl p=twig q=twig r=twig]
15−In a program, it is used like so:
23−Here the `=(0 a)` is `p`, the `b` is `q`, and the bottom line is the
26−There are several benefits to using runes in lieu of reserved words.
27−First, it prevents the programmer from accidentally misusing a reserved
28−word as a variable name, which also allows her to be sure that any word
29−in her progam is an identifier. Next, as the first ASCII symbol of the
30−rune digraphs bears semantic significance, the programmer can look at
31−any rune and immediately have a basic, intuitive understanding as to
34−Next, rune syntax addresses several issues that arise in other
35−languages. First, it produces cleaner, less verbose code that
36−conveniently flows downward. To highlight the verbosity Hoon avoids by
37−implementing runes, here is the C equivalent of the `++add` source code
41− function(left-operand: atom, right-operand: atom)
43− if equals(0, left-operand) {
46− recurse(left-operand (decrement left-operand)),
47− right-operand (increment right-operand))
51−What is more, Hoon solves two problems that arise in functional
52−programming languages with very deep expression trees: first, the
53−collection of huge piles of closing parens at the end of large blocks;
54−and second, the fact that the depth of expression trees are thus bounded
55−by the width of the text box, as subexpressions tend to be indented.
56−Some languages solve the bracket-terminator problem by parsing
57−whitespace in order to use indentation to express tree depth:
64−While this is actually valid Hoon, it does not solve the width problem.
66−To address this problem, most Hoon `++twigs` have a short, fixed
67−fan-out. Thus, the parser does not need significant whitespace nor a
68−terminator to determine how many twigs follow a `?:`--it already knows
69−that the answer is three. A smart parser allows the Hoon programmer to
70−format her code using a [backstep pattern]() that allows her to descend
71−into a deep tree without losing right margin.
73−Lastly, but perhaps most significantly, code is meant to be seen, and
74−not read. Anyone who has even slight experience coding Hoon will tell
75−you that they can understand and connect with properly formatted Hoon
76−code on a deeper, more intuitive level that cannot be explained but must
77−be experienced. One doesn't read `++add`, she sees it.
82−While the second glyph in a rune means little or nothing, the first
83−defines a rough semantic category:
85− | bar Core construction
86− $ buc Tile construction
88− : col Tuple construction
89− . dot Nock operations
90− # hax Pretty printing
91− ^ ket Type conversions
92− ; sem Composers (and XML generators)
94− = tis Subject modifiers
95− ? wut Conditionals, booleans, and tests
96− ! zap Special operations
98−As shown above, each glyph has its own monosyllabic name, designed to be
99−pronounced quickly in combination with another glyph to form a rune
100−name. As languages are often read-aloud, this saves the programmer from
101−having to say "dollar sign, question mark"--"bucwut" is much more
104−Irregular pronuncations
105−-----------------------
107−To avoid a few tongue-twisters, some runes have irregular pronunciations
108−that should be noted:
115−Note: these runes are not members of any of the categories above, but
116−are mostly used to....