on master help sign in
Proper commit of hoon reorg.
30fa28aC. Guy Yarvin
docs/programming/hoon/advanced.mdnew file+197
@@ -0,0 +1,197 @@
1+---
2+sort: 7
3+next: true
4+title: Advanced types
5+---
6+
7+# Advanced types
8+
9+As we noted, the definition of `span` in the last chapter is a
10+subset. The Hoon type system is simple, but not *that* simple.
11+
12+The good news is that you can *skip this section*, at least when
13+you're first learning Hoon. Polymorphism and aliasing are mainly
14+for advanced programmers writing complex infrastructure and/or
15+large functions. Don't worry about them for a little while.
16+
17+## The complete, uncensored `span`
18+
19+```
20+++ span $@ $? $noun
21+ $void
22+ == $% {$atom p/term q/(unit atom)}
23+ {$cell p/span q/span}
24+ {$core p/span q/coil}
25+ {$face p/$@(term tune) q/span}
26+ {$fork p/(set span)}
27+ {$hold p/span q/twig}
28+ ==
29+::
30+++ coil $: p/?($gold $iron $lead $zinc)
31+ q/span
32+ r/{p/?($~ ^) q/(map term foot)}
33+ ==
34+++ foot $% {$dry p/twig}
35+ {$wet p/twig}
36+ ==
37+++ tune
38+ $: p/(map term (unit twig))
39+ q/(list twig)
40+ ==
41+```
42+
43+If you compare this to the basic `span`, you'll see that we've
44+changed two stems: `$core` and `$face`. We added polymorphism to
45+`$core`, aliases and bridges to `$face`.
46+
47+## `$core`: advanced polymorphism
48+
49+If cores never changed, we wouldn't need polymorphism. Of
50+course, nouns are immutable and never change, but we use them as
51+templates to construct a new noun
52+
53+Suppose we take a core, a cell `{battery payload}`, and replace
54+the payload with a different noun. Then, we invoke an arm from
55+the battery.
56+
57+Is this legal? Does it make sense? Every function call in Hoon
58+does this, so we'd better make it work well.
59+
60+The full core stores both payload spans. The span that describes
61+the payload currently in the core is `p`. The span that describes
62+the payload the core was compiled with is `q.q`.
63+
64+In the Bertrand Meyer tradition of type theory, there are two
65+forms of polymorphism: variance and genericity. In Hoon this
66+choice is per arm, which is why our battery went from `(map term
67+twig)` to `(map term foot)` when it went into the coil. A `foot`
68+is `$dry` or `$wet`. Dry polymorphism relies on variance; wet
69+polymorphism relies on genericity.
70+
71+### Dry arms
72+
73+For a dry arm, we apply the Liskov substitution principle: we
74+ask, "can we use any `p` as if it was a `q.q`"? This is the same
75+test as in `:cast` or any type comparison (`nest`). Intuitively,
76+we ask: is the new payload compatible with the old payload?
77+
78+For a core `a`, if `p.a` fits in `q.q.a`, we can use arms on the
79+core. The product of an dry arm whose twig is `b` is always
80+defined as `{$hold a(p q.q.a, p.q %gold) b}`.
81+
82+In other words, the subject of the arm computation is the
83+original core span. The span of the modified payload, `p`, is
84+thrown away. This is of course the normal behavior of a function
85+call in most languages.
86+
87+### Dry polymorphism and core nesting rules
88+
89+Dry polymorphism works by substituting cores. Typically, the
90+the programmer uses one core as an interface definition, then
91+replace it with another core which does something useful.
92+
93+For core `b` to nest within core `a`, the batteries of `a` and
94+`b` must have the same tree shape, and the product of each `b`
95+arm must nest within the product of the `a` arm. Wet arms (see
96+below) are not compatible unless the twig is exactly the same.
97+
98+But we also apply a payload test that depends on the rules of
99+variance. Again, this is traditional Meyer type theory; don't
100+worry if you don't know it. These rules should make sense if you
101+just think about them intuitively.
102+
103+Each core has a "metal" `p.q` which defines its variance model.
104+A core can be *invariant* (`$gold`), *bivariant* (`$lead`),
105+*covariant* (`$zinc`), or *contravariant* (`$iron`). The default
106+is gold; a gold core can be converted to any metal, and any metal
107+can be converted to lead.
108+
109+A gold core `a` has a read-write payload; another core `b` that
110+nests within it (ie, can be substituted for it) must be a gold
111+core whose payload is mutually compatible (`+3.a` nests in `+3.b`,
112+`+3.b` nests in `+3.a`). Hence, *invariant*.
113+
114+A lead core `a` has an opaque payload. There is no constraint on
115+the payload of a core `b` which nests within it. Hence,
116+*bivariant*.
117+
118+An iron core `a` has a write-only sample (payload head, `+6.a`)
119+and an opaque context (payload tail, `+7.a`). A core `b` which
120+nests within it must be a gold or iron core, such that `+6.a`
121+nests within `+6.b`. Hence, *contravariant*.
122+
123+A zinc core `a` has a read-only sample (payload head, `+6.a`)
124+and an opaque context (payload tail, `+7.a`). A core `b` which
125+nests within it must be a gold or zinc core, such that `+6.b`
126+nests within `+6.a`. Hence, *covariant*.
127+
128+### Wet arms
129+
130+For a wet arm, we ask: suppose this core was actually compiled
131+using `p` instead of `q.q`? Would the Nock formula we generated
132+for `q.q` actually work for a `p` payload?
133+
134+A wet arm with twig `b` in core `a` produces the span `{$hold a
135+b}`. Assuming `a` has a modified payload, this will (lazily)
136+analyze the arm with the caller's modified payload, `p`.
137+
138+But of course, we don't actually recompile the arm at runtime.
139+We actually run the formula generated for the original payload,
140+`q.q`.
141+
142+When we call a wet arm, we're essentially using the twig as a
143+macro. We are not generating new code for every call site; we
144+are creating a new type analysis path, which works as if we
145+expanded the callee with the caller's context.
146+
147+Consider a function like `turn` (Haskell `map`) which transforms
148+each element of a list. To use `turn`, we install a list and a
149+transformation function in a generic core. The span of the list
150+we produce depends on the span of the list and the span of the
151+transformation function. But the Nock formulas for transforming
152+each element of the list will work on any function and any list,
153+so long as the function's argument is the list item.
154+
155+Again, will this work? A simple (and not quite right) way to ask
156+this question is to compile all the twigs in the battery for both
157+a payload of `p` and a payload of `q.q`, and see if they generate
158+exactly the same Nock. The actual algorithm is a little more
159+interesting, but not much.
160+
161+A Haskeller might say that in a sense, `q.q` and `q.r.q` (the
162+original payload and the battery) define a sort of implicit
163+typeclass. And indeed, Hoon uses wet arms for the same kinds of
164+problems as Haskell typeclasses.
165+
166+Like typeclasses, wet arms / gates are a powerful tool. Don't
167+use them unless you know what you're doing.
168+
169+### Constant folding
170+
171+There's only one field of the `coil` we haven't explained yet:
172+`p.r.q`. This is simply the compiled battery, if available. (Of
173+course, we compile the twigs in a core against the core itself,
174+and the formulas can't be available while we're compiling them.)
175+External users of the core want this battery constant, though: it
176+lets us fold constants by executing arms at compile time.
177+
178+## `$face`: aliases and bridges
179+
180+In the advanced `tune` form, the `$face` span also has a couple
181+of secret superpowers for hacking the namespace. Remember that
182+Hoon doesn't have anything like a symbol table; to resolve a
183+limb, we just search the span depth-first.
184+
185+If a name is in the `p.p` map, it's an alias. The map contains a
186+`(unit twig)`; if the unit is full, the name resolves to that
187+twig (compiled against the `q` span). If the unit is empty,
188+the name is blocked / skipped (see [limb](twig/limb) for what
189+this means).
190+
191+If a name is in the `q.p` map, it's a bridge. When we search for
192+a name, we also compile the bridge, and check if the name
193+resolves against the bridge product. If so, we use it.
194+
195+These hacks let us deal with interesting large-scale problems,
196+like complex library dependencies. You definitely don't need to
197+understand them to just write simple Hoon programs.
docs/programming/hoon/span.md → docs/programming/hoon/basic.mdrenamed+23−31
@@ -1,14 +1,16 @@
1---
1---
2−sort: 6
2+sort: 5
3next: true
3next: true
4−title: Type: span
4+title: Basic types
5---
5---
6
6
7−# Type: `span`
7+# Basic types
8
8
9A `span` is a set of nouns and an interpretation of these nouns.
9A `span` is a set of nouns and an interpretation of these nouns.
10+Officially, we don't use the word "type" in Hoon. But if we had
11+to say "type," it would mean `span`.
10
12
11−## Span, mold, type: what's in a type system?
13+## Span and mold
12
14
13There is no Hoon syntax for a span. The programmer never defines
15There is no Hoon syntax for a span. The programmer never defines
14a span explicitly. It is always produced as the inferred range
16a span explicitly. It is always produced as the inferred range
@@ -26,8 +28,8 @@ the standard form is useful. The standard form is a constructor
26function, or *mold*.
28function, or *mold*.
27
29
28A mold is an idempotent function (`gate`), accepting any noun.
30A mold is an idempotent function (`gate`), accepting any noun.
29−(An idempotent function is one such that f(f(x)) equals f(x) if
31+(An idempotent function is one such that *f(f(x))* equals *f(x)*
30−f(x) does not crash.) The product range of the function is the
32+if *f(x)* terminates.) The product range of the function is the
31span, or *icon*, of the mold.
33span, or *icon*, of the mold.
32
34
33Usually we use molds purely in the first sense: as an abstract
35Usually we use molds purely in the first sense: as an abstract
@@ -35,29 +37,16 @@ definition of a noun. Don't actually call a mold unless you're
35actually validating untrusted foreign data. As a beginner,
37actually validating untrusted foreign data. As a beginner,
36hopefully you aren't!
38hopefully you aren't!
37
39
38−(It's also important to remember that any twig can be a mold.
39−Some stems are macros designed for making molds, but a mold is
40−defined by how it's used, not what it's made of. The Hoon type
41−system cannot even check the mold definition, since Hoon lacks
42−dependent type and therefore can't verify idempotence.)
43−
44−To summarize: a Hoon "type declaration" is the definition of a
45−function, the mold. A mold and a span are different things. A
46−mold is a constructor. A span defines a set of nouns, possibly
47−infinite, and annotates them with semantics.
48−
49−Either mold or span could be called a "type," but not both. We
50−often say "type" in Hoon. But we always mean it informally.
51−Ideally, the meaning is obvious from context. ("Type" can also
52−mean a `mark`, Urbit's equivalent of a MIME type.)
53−
54−## The `span` mold
40+## The `span` mold (simplified)
55
41
56Usually in Hoon we define the semantics of a primitive by the
42Usually in Hoon we define the semantics of a primitive by the
57state the span of all nouns that implement that primitive. We
43state the span of all nouns that implement that primitive. We
58state this span as the icon of a mold. That mold is produced by
44state this span as the icon of a mold. That mold is produced by
59a kernel arm `span`:
45a kernel arm `span`:
60
46
47+This is a slightly simplified version of `span`. We'll undo and
48+explain the simplifications below.
49+
61```
50```
62++ term @tas
51++ term @tas
63++ span
52++ span
@@ -65,7 +54,7 @@ a kernel arm `span`:
65 $void
54 $void
66 == $% {$atom p/term q/(unit atom)}
55 == $% {$atom p/term q/(unit atom)}
67 {$cell p/span q/span}
56 {$cell p/span q/span}
68− {$core p/span q/(map term span)}
57+ {$core p/span q/(map term twig)}
69 {$face p/term q/span}
58 {$face p/term q/span}
70 {$fork p/(set span)}
59 {$fork p/(set span)}
71 {$hold p/span q/twig}
60 {$hold p/span q/twig}
@@ -78,26 +67,29 @@ pseudocode. If a span is an atom, it's either the atomic string
78`atom`, `cell`, `core`, etc. We'll go through each of these
67`atom`, `cell`, `core`, etc. We'll go through each of these
79cases below.
68cases below.
80
69
81−## `$noun` and `$void`
70+### `$noun` and `$void`
82
71
83`$noun` is the set of all nouns. `$void` is the set of no nouns.
72`$noun` is the set of all nouns. `$void` is the set of no nouns.
84
73
85−## `{$cell p/span q/span}`
74+### `{$cell p/span q/span}`
86
75
87`{$cell p/span q/span}` is the set of all cells with head `p` and
76`{$cell p/span q/span}` is the set of all cells with head `p` and
88tail `q`.
77tail `q`.
89
78
90−## `{$fork p/(set span)}
79+### `{$fork p/(set span)}
91
80
92`{$fork p/(set span)}` is the union of all spans in the set `p`.
81`{$fork p/(set span)}` is the union of all spans in the set `p`.
93
82
94−## `{$hold p/span q/twig}`
83+### `{$hold p/span q/twig}`
95
84
96A `$hold` span, with span `p` and twig `q`, is a lazy reference
85A `$hold` span, with span `p` and twig `q`, is a lazy reference
97to the span of `(mint p q)`. In English it means: "the type of
86to the span of `(mint p q)`. In English it means: "the type of
98the product when we compile `q` against subject `p`.
87the product when we compile `q` against subject `p`.
99
88
89+This is "manual laziness." Hoon is a strict language, so we have
90+to express
91+
100−## `{$face p/term q/span}
92+### `{$face p/term q/span}
101
93
102A `{$face p/term q/span}` wraps the label `p` around the span
94A `{$face p/term q/span}` wraps the label `p` around the span
103`q`. `p` is a `term` or `@tas`, an atomic ASCII string which
95`q`. `p` is a `term` or `@tas`, an atomic ASCII string which
@@ -107,7 +99,7 @@ first character must be lowercase.
107See the [twig chapter](twig) for how labels are resolved. It's
99See the [twig chapter](twig) for how labels are resolved. It's
108nontrivial.
100nontrivial.
109
101
110−## `{%atom p/term q/(unit atom))}
102+### `{%atom p/term q/(unit atom))}
111
103
112An `$atom` is an atom, with two twists. `q` is a `unit`, Hoon's
104An `$atom` is an atom, with two twists. `q` is a `unit`, Hoon's
113equivalent of a nullable pointer or a Haskell `Maybe`. If `q`
105equivalent of a nullable pointer or a Haskell `Maybe`. If `q`
@@ -131,7 +123,7 @@ statically, by casting through the empty aura `@`. Hoon is not
131dependently typed and can't statically enforce data constraints
123dependently typed and can't statically enforce data constraints
132(for example, it can't enforce that a `@tas` is really a symbol).
124(for example, it can't enforce that a `@tas` is really a symbol).
133
125
134−## `{$core p/span q/(map term span)}
126+### `{$core p/span q/(map term span)}
135
127
136A `$core` is a code-data cell. The data (or *payload*) is the
128A `$core` is a code-data cell. The data (or *payload*) is the
137tail; the code (or *battery*) is the head. `p`, a span, is the
129tail; the code (or *battery*) is the head. `p`, a span, is the
docs/programming/hoon/catalog.md+14−14
@@ -1,76 +1,76 @@
1---
1---
2sort: 10
2sort: 10
3−title: Stems catalog
3+title: Twig reference
4---
4---
5
5
6−# Stems
6+# Twig reference
7
7
8−#### A catalog of all Hoon stems:
8+#### A catalog of all twig stems:
9
9
10<div class="book">
10<div class="book">
11
11
12## `$ buc` (mold)
12## `$ buc` (mold)
13
13
14−<list src="buc-mold" dataPreview="true" className="runes" childIsFragment="true"></list>
14+<list src="../twig/buc-mold" dataPreview="true" className="runes" childIsFragment="true"></list>
15
15
16---
16---
17
17
18## `| bar` (core)
18## `| bar` (core)
19
19
20−<list src="bar-core" dataPreview="true" className="runes" childIsFragment="true"></list>
20+<list src="../twig/bar-core" dataPreview="true" className="runes" childIsFragment="true"></list>
21
21
22---
22---
23
23
24## `: col` (cell)
24## `: col` (cell)
25
25
26−<list src="col-cell" dataPreview="true" className="runes" childIsFragment="true"></list>
26+<list src="../twig/col-cell" dataPreview="true" className="runes" childIsFragment="true"></list>
27
27
28---
28---
29
29
30## `% cen` (call)
30## `% cen` (call)
31
31
32−<list src="cen-call" dataPreview="true" className="runes" childIsFragment="true"></list>
32+<list src="../twig/cen-call" dataPreview="true" className="runes" childIsFragment="true"></list>
33
33
34---
34---
35
35
36## `. dot` (nock)
36## `. dot` (nock)
37
37
38−<list src="dot-nock" dataPreview="true" className="runes" childIsFragment="true"></list>
38+<list src="../twig/dot-nock" dataPreview="true" className="runes" childIsFragment="true"></list>
39
39
40---
40---
41
41
42## `^ ket` (cast)
42## `^ ket` (cast)
43
43
44−<list src="ket-cast" dataPreview="true" className="runes" childIsFragment="true"></list>
44+<list src="../twig/ket-cast" dataPreview="true" className="runes" childIsFragment="true"></list>
45
45
46---
46---
47
47
48## `~ sig` (hint)
48## `~ sig` (hint)
49
49
50−<list src="sig-hint" dataPreview="true" className="runes" childIsFragment="true"></list>
50+<list src="../twig/sig-hint" dataPreview="true" className="runes" childIsFragment="true"></list>
51
51
52---
52---
53
53
54## `; sem` (make)
54## `; sem` (make)
55
55
56−<list src="sem-make" dataPreview="true" className="runes" childIsFragment="true"></list>
56+<list src="../twig/sem-make" dataPreview="true" className="runes" childIsFragment="true"></list>
57
57
58---
58---
59
59
60## `= tis` (flow)
60## `= tis` (flow)
61
61
62−<list src="tis-flow" dataPreview="true" className="runes" childIsFragment="true"></list>
62+<list src="../twig/tis-flow" dataPreview="true" className="runes" childIsFragment="true"></list>
63
63
64---
64---
65
65
66## `? wut` (test)
66## `? wut` (test)
67
67
68−<list src="wut-test" dataPreview="true" className="runes" childIsFragment="true"></list>
68+<list src="../twig/wut-test" dataPreview="true" className="runes" childIsFragment="true"></list>
69
69
70---
70---
71
71
72## `! zap` (wild)
72## `! zap` (wild)
73
73
74−<list src="zap-wild" dataPreview="true" className="runes" childIsFragment="true"></list>
74+<list src="../twig/zap-wild" dataPreview="true" className="runes" childIsFragment="true"></list>
75
75
76</div>
76</div>
docs/programming/hoon/catalog/bar-core.mddeleted−29
@@ -1,29 +0,0 @@
1−---
2−sort: 1
3−---
4−
5−# `| bar` (core)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ foot
16− $% {$dry p/twig}
17− {$wet p/twig}
18− ==
19−::
20−++ twig
21− $% {$door p/moss q/(map term foot)} :: |_
22− {$core p/(map term foot)} :: |%
23− {$trap p/twig} :: |.
24− {$loop p/twig} :: |-
25− {$gill p/moss q/twig} :: |*
26− {$gate p/moss q/twig} :: |=
27− ==
28−--
29−```
docs/programming/hoon/catalog/buc-mold.mddeleted−26
@@ -1,26 +0,0 @@
1−---
2−sort: 2
3−---
4−
5−# `$ buc` (mold)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$claw p/moss q/moss} :: $@
17− {$shoe p/twig} :: $_
18− {$bank p/(list moss)} :: $:
19− {$book p/(list moss)} :: $%
20− {$lamb p/moss q/moss} :: $-
21− {$bush p/moss q/moss} :: $^
22− {$pick p/(list moss)} :: $?
23− {$coat p/term q/moss} :: $=
24− ==
25−--
26−```
docs/programming/hoon/catalog/cen-call.mddeleted−27
@@ -1,27 +0,0 @@
1−---
2−sort: 4
3−---
4−
5−# `% cen` (call)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$bunt p/twig} :: %$
17− {$keep p/wing q/(list (pair wing twig))} :: %_
18− {$lace p/twig q/twig} :: %.
19− {$call p/twig q/(list twig)} :: %-
20− {$bake p/wing q/twig r/(list (pair wing twig))} :: %*
21− {$calq p/twig q/twig r/twig s/twig} :: %^
22− {$calt p/twig q/twig r/twig} :: %+
23− {$open p/wing q/twig r/(list twig)} :: %~
24− {$make p/wing q/(list (pair wing twig))} :: %=
25− ==
26−--
27−```
docs/programming/hoon/catalog/col-cell.mddeleted−24
@@ -1,24 +0,0 @@
1−---
2−sort: 3
3−---
4−
5−# `: col` (cell)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$scon p/twig q/twig} :: :_
17− {$conq p/twig q/twig r/twig s/twig} :: :^
18− {$cons p/twig q/twig} :: :-
19− {$cont p/twig q/twig r/twig} :: :+
20− {$conl p/(list twig)} :: :~
21− {$conp p/(list twig)} :: :*
22− ==
23−--
24−```
docs/programming/hoon/catalog/ket-cast.mddeleted−24
@@ -1,24 +0,0 @@
1−---
2−sort: 6
3−---
4−
5−# `^ ket` (cast)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$iron p/twig} :: ^|
17− {$like p/twig q/twig} :: ^+
18− {$cast p/twig q/twig} :: ^-
19− {$zinc p/twig} :: ^&
20− {$burn p/twig} :: ^~
21− {$name p/toga q/twig} :: ^=
22− {$lead p/twig} :: ^?
23− ==
24−--
docs/programming/hoon/catalog/misc.mddeleted−50
@@ -1,50 +0,0 @@
1−---
2−sort: 12
3−---
4−
5−# Irregular leaves
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ base :: base mold
16− $@ $? $noun :: any noun
17− $cell :: any cell
18− $bean :: loobean
19− $void :: no nouns
20− $null :: ~ == 0
21− == ::
22− {$atom p/odor} :: atom
23−:: ::
24−++ pint {p/{p/@ q/@} q/{p/@ q/@}} :: line+column range
25−++ spot {p/path q/pint} :: range in file
26−++ woof $@(@ {$~ p/twig}) :: string w/embed
27−:: ::
28−++ tune :: complex face
29− $: p/(map term (unit twig)) :: definitions
30− q/(list twig) :: bridges
31− == ::
32−:: ::
33−++ twig ::
34− $% {$base p/base} :: base
35− {$bust p/base} :: bunt base
36− {$dbug p/spot q/twig} :: debug info in trace
37− {$hand p/span q/nock} :: premade result
38− {$knit p/(list woof)} :: assemble string
39− {$leaf p/(pair term @)} :: symbol
40− {$limb p/term} :: pulls limb p
41− {$lost p/twig} :: not to be taken
42− {$rock p/term q/*} :: fixed constant
43− {$sand p/term q/*} :: unfixed constant
44− {$tell p/(list twig)} :: render as tape
45− {$tune p/$@(term tune)} :: face on subject
46− {$wing p/wing} :: pulls p
47− {$yell p/(list twig)} :: render as tank
48− ==
49−--
50−```
docs/programming/hoon/catalog/misc/base.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/buc-bunt.mddeleted−5
@@ -1,5 +0,0 @@
1−---
2−sort: 7
3−---
4−
5−`:bunt`, {$bunt p/moss}
docs/programming/hoon/catalog/misc/bust.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/dbug.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/hand.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/knit.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/leaf.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/limb.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/lost.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/rock.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/sand.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/tell.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/tune.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/wing.mddeleted

No changes to the content.

docs/programming/hoon/catalog/misc/yell.mddeleted

No changes to the content.

docs/programming/hoon/catalog/sem-make.mddeleted−22
@@ -1,22 +0,0 @@
1−---
2−sort: 9
3−---
4−
5−# `; sem` (make)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$wad p/twig q/(list twig)} :: ;:
17− {$nub p/twig} :: ;/
18− {$dip p/twig q/(list twig)} :: ;~
19− {$fry p/twig q/twig} :: ;;
20− ==
21−--
22−```
docs/programming/hoon/catalog/sig-hint.mddeleted−36
@@ -1,36 +0,0 @@
1−---
2−sort: 7
3−---
4−
5−# `~ sig` (hint)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ chum :: jet hint
16− $? lef/term :: jet name
17− {std/term kel/@} :: kelvin version
18− {ven/term pro/term kel/@} :: vendor and product
19− {ven/term pro/term ver/@ kel/@} :: all of the above
20− == ::
21−:: ::
22−++ twig ::
23− $% {$show p/twig q/twig} :: ~|
24− {$lurk p/twig q/twig} :: ~_
25− {$fast p/chum q/twig r/tyre s/twig} :: ~%
26− {$funk p/chum q/twig} :: ~/
27− {$thin p/$@(term {p/term q/twig}) q/twig} :: ~<
28− {$hint p/$@(term {p/term q/twig}) q/twig} :: ~>
29− {$poll p/term q/twig} :: ~$
30− {$memo p/@ q/twig} :: ~+
31− {$dump p/@ud q/twig r/twig} :: ~&
32− {$ddup p/twig q/twig} :: ~=
33− {$warn p/@ud q/twig r/twig s/twig} :: ~?
34− {$peep p/twig q/twig} :: ~!
35− ==
36−--
docs/programming/hoon/catalog/tis-flow.mddeleted−31
@@ -1,31 +0,0 @@
1−---
2−sort: 8
3−---
4−
5−# `= tis` (flow)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ taco $@(term (pair term twig)) :: optional face
16−++ twig ::
17− $% {$new p/twig q/twig} :: =|
18− {$fix p/(list (pair wing twig)) q/twig} :: =:
19− {$var p/taco q/twig r/twig} :: =/
20− {$rev p/taco q/twig r/twig} :: =;
21− {$set p/wing q/twig r/twig} :: =.
22− {$rap p/twig q/twig} :: =<
23− {$nip p/twig q/twig} :: =-
24− {$per p/twig q/twig} :: =>
25− {$sip p/taco q/wing r/twig s/twig} :: =^
26− {$pin p/twig q/twig} :: =+
27− {$tow p/(list twig)} :: =~
28− {$aka p/term q/twig r/twig} :: =*
29− ==
30−--
31−```
docs/programming/hoon/catalog/wut-test.mddeleted−31
@@ -1,31 +0,0 @@
1−---
2−sort: 10
3−---
4−
5−# `? wut` (test)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$or p/(list twig)} :: ?|
17− {$case p/wing q/(list (pair twig twig))} :: ?-
18− {$if p/twig q/twig r/twig} :: ?:
19− {$lest p/twig q/twig r/twig} :: ?.
20− {$ifcl p/wing q/twig r/twig} :: ?^
21− {$deny p/twig q/twig} :: ?<
22− {$sure p/twig q/twig} :: ?>
23− {$deft p/wing q/twig r/(list (pair twig twig))} :: ?+
24− {$and p/(list twig)} :: ?&
25− {$ifat p/wing q/twig r/twig} :: ?@
26− {$ifno p/wing q/twig r/twig} :: ?~
27− {$fits p/twig q/wing} :: ?=
28− {$not p/twig} :: ?!
29− ==
30−--
31−```
docs/programming/hoon/catalog/zap-wild.mddeleted−23
@@ -1,23 +0,0 @@
1−---
2−sort: 11
3−---
4−
5−# `! zap` (wild)
6−
7−<list dataPreview="true" className="runes" linkToFragments="true"></list>
8−
9−<kids className="runes"></kids>
10−
11−## Twigs
12−
13−```
14−|%
15−++ twig
16− $% {$twig p/twig q/twig} :: !,
17− {$wrap p/twig} :: !>
18− {$spit p/twig q/twig} :: !;
19− {$code p/twig} :: !=
20− {$need p/$@(p/@ {p/@ q/@}) q/twig} :: !?
21− {$fail $~} :: !!
22− ==
23−--
docs/programming/hoon/cheat-sheets.mddeleted−9
@@ -1,9 +0,0 @@
1−---
2−sort: 13
3−---
4−
5−# Quick references
6−
7−Some quick-reference sheets to print out or keep on your other monitor.
8−
9−<list></list>
docs/programming/hoon/cheat-sheets/hoon.mddeleted−532
@@ -1,532 +0,0 @@
1−
2−##Quick references
3−
4−###Lexical syntax
5−
6−####Comments
7−
8−`::` all code following '::' on a line is a comment.
9−
10−By convention, comments should begin on either column 39 or
11−column 57.
12−
13−####Runes (Expressions)
14−
15−- Most runes have a predetermined amount of children, and thus do not need to be closed.
16−
17−- Runes that accept an arbitrary number of children are typically closed with
18− `==`, with the exception being the `|` runes, some of which are closed with
19− `--`.
20−
21−- In some cases, the second glyph denotes how many 'children' a rune accepts:
22−
23− `-` two
24− `+` three
25− `^` four
26−
27−- Backstep pattern: in order to avoid excess parentheses as well as code that
28− flows off the page, the last child of a rune should fall directly below it.
29− The first child should be the furthest to the right, with every subsequent
30− rune 'backstepping' two spaces towards the last child.
31−
32− XX
33−
34−The first glyph in a rune defines a rough semantic category of expressions:
35−
36−##### ? : Conditional statements
37−
38−`?&` Logical "and"
39−
40− - Irregular: `&`
41−
42−`?|` Logical "or"
43−
44− - Irregular: `|.`
45−
46−`?!` Logical "not"
47−
48− - Irregular: `!`
49−
50−
51−`?:` - If-then-else
52−
53−`?.` - Inverted if-then-else
54−
55−`?@` - If atom-then-else
56−
57−`?^` - If cell-then-else
58−
59−
60−`?-` - Switch (on type)
61−
62−`?+` - Swith (on type) with default
63−
64−
65−`?>` - Assert `p` is false.
66−
67−`?<` - Assert `p` is true.
68−
69−
70−`?~` - if null-then-else Note: don't forget, changes type
71−`?=` - is `q` of type `p`Note: don't forget, changes the type
72−
73−##### % : Code execution
74−
75−`%-` Call `p` with 1 arg
76−
77− - Irregular: `(p q)` Note: irregular form can accept n children.
78−
79−`%.` Inverted `%-`: call `q` with arg `p`
80−
81−`%+` Call `p` with 2 args
82−
83−`%^` Call `p` with 3 args
84−
85−
86−`%~` Call one arm `p` within object/core `q` with arg `r`
87−
88− - Irregular: `~(p q r)`
89−
90−`%*` Same as `%~` except `s` is a list of changes that can be made anywhere in
91−the context, not just to input data.
92−
93−
94−`%=` Evaluate `p` with changes specified in `q`
95−
96− - Irregular: `a(p q.p, q p.a)`, where `a` is the code to be executed with changes
97− specified in the `()`
98−
99−`%_` Same as `%=`, except that product is cast back to type of `p`.
100−
101−##### : : Tuple construction
102−
103−`:-` Tuple of two
104−
105− - Irregular `[p q ..]` Note: the irregular form can make tuples of arbitrary size
106−
107−`:_` Inverted tuple of two
108−
109−`:+` Tuple of three
110−
111−`:^` Tuple of four
112−
113−
114−`:*` Tuple of arbitrary number of elements, closed with `==`
115−
116−`:~` Null terminated tuple of arbitrary number of elements, closed with `==`.
117−
118−
119−`:/` XX
120−
121−##### | : Object aka "core" construction
122−
123−`|%` Generic core, closed with `--`
124−
125−`|_` Core with input data (aka 'sample), closed with `--`
126−
127−
128−`|=` Function with type-checking at compile time (aka 'dry gate'); called automatically
129−
130−`|*` Function with type-checking at run time (aka 'wet gate'); called automatically
131−
132−`|.` Function (like `|=`) with no argument; called automatically
133−
134−`|-` Function with no arguments (like `|.`); not called automatically
135−
136−
137−`|/` Same as `|_`, but with well typed output, closed with `--`
138−
139−`|^` Same as `|-`, but can contain internal arms, closed with `--`
140−
141−`|+` Function with unreadable argument(s) (aka 'sample'), so as to avoid type conflicts
142−
143−`|?` Same as `|_` but both the input and 'context' are hidden to avoid type conflicts
144−
145−##### $ : Type definitions
146−
147−`$|` Union between atom and cell
148−
149−`$_` 'Unbunt'; create type from example
150−
151− - Irregular: `_p`, but only when in mold syntax
152−
153−`$:` Tuple of types (aka 'molds')
154−
155− - Irregular: `{i.p i.t.p i.t.t.p}`
156−
157−`$%` Tagged union
158−
159−`$+` Type of function (type signature)
160−
161−`$&` Union of two cells: one w/cellular head and other w/atomic head
162−
163−`$*` 'Bunt'; produce default value of a type
164−
165− - Irregular: `*([mold])`
166−
167−`$=` Add variable name; technically changes the type as well
168−
169− - Irregular: `p=q`, but only when in mold syntax
170−
171−`$?` Union of types; non-empty list of types ('molds'). Default value ('bunt') is the value of the first element
172−
173− - Irregular: `?([list of molds])`, but only when in mold syntax
174−
175−##### = : Subject ("context") modification XX
176−
177−`=>` Resolve code; use the product of `p` as the subject of `q`
178−
179− - Irregular: `p:q`
180−
181−`=<` Inverted `=>`, used for code readability
182−
183−
184−`=|` Push default value of type ('mold') onto subject
185−
186−`=+` Push variable/value onto subject
187−
188−`=-` Inverted `=+`; push product of `q` onto subject `p`
189−
190−
191−`=.` One change to subject; produce `r` with `p` in the context (in hoon the
192−'subject') set to `q`
193−
194−`=:` Multiple changes to subject; Make a list of changes to the context (in hoon the 'subject')
195−
196− XX how do we talk about subject and context.
197−
198−
199−`=^` Used to push a new variable `q` with face `p` onto the subject `s`, as
200−well as to change the value of another. `r` is a function that accepts `q` and
201−produces a cell of a new value of `q`, and a new subject. XX
202−
203−`=~` Compose a list of twigs, applying `=>` to the list, using each result as the subject to the subsequent expressions.
204−
205−`=*` Make `p` an alias of `q`
206−
207−##### ^ : Casting
208−
209−`^|` Make core context unreadable so as to avoid type conflicts
210−
211−`^.` Cast `q` to the product type of `p`. Useful when you don't actually want to run a funciton at run time
212−
213−`^-` Traditional Cast `q` to the type of the default value ('bunt') of `p`
214−
215− - `\`p\`q`
216−
217−`^+` Cast `q` to the type of `p`. Used to cast to types that have previously been made into validator functions with `$,`.
218−
219−`^&` Convert object/core from invariant to covariant
220−
221−`^~` Try to execute `p` statically at compile time. If this fails, `p` remains dynamic
222−
223−`^=` Put on variable name ('face')
224−
225− - Irregular: `p=q`
226−
227−`^?` Convert core with unreadable context to a core whose input ('sample') and context are unreadable. Used to avoid type conflicts
228−
229−##### . : Nock operations
230−
231−`.^` Nock 11; loads a file from `%clay`
232−
233−`.+` Nock 4; increments an atom
234−
235− - Irregular: `+(p)`
236−
237−`.*` Compute nock; formula `q` on subject `p`
238−
239−`.=` Nock 5; test `p` and `q` for equality
240−
241− - Irregular: `=(p q)`
242−
243−`.?` Test if noun is cell or an atom
244−
245−##### # : Pretty printing
246−
247−`#<` Pretty print tape; only used in its irregular form
248−
249− - Irregular: `<i.p i.t.p i.t.t.p>`
250−
251−`#>` Pretty print `++tank`; used only in it's irregular form
252−
253− - Irregular: `>i.p i.t.p i.t.t.p<`
254−
255−##### / : Library access
256−
257−`//` Load a file between twigs
258−
259−`/~` Cached computation, similar to a `=+` at the top of the file
260−
261−`/$` Pull in dynamic request data, slam it through a gate
262−
263−`/=` Horn form of `^=`. Puts a face on a cached computation
264−
265−`/^` Horn form of `^-`
266−
267−`/;` Apply gate to result of horn
268−
269−`/,` Appen path to current working beam before computing horn
270−
271−`/:` Replace beam
272−
273−`/%` Reifiy the 'heel' virtual path, letting any requested resource interpret it further
274−
275−`/.` Construct list of specified horns
276−
277−`/*` similar to `/.`, but produces a map instead
278−
279−`/_` descend into each available subdirectory, construct a map from all successfully building versions
280−
281−`/&` Parse directory name as `@da`
282−
283−`/|` Parse directory name as `@dr`
284−
285−##### ~ : Compiler hints
286−
287−`~$` Label computation `q` as `p` for profiling
288−
289−`~|` `p` in stacktrace if `q` crashes
290−
291−`~_` Preformatted stackframe `p` (a trap producing a `++tank`) into stacktrace
292−
293−`~%` i.p i.t.p i.t.t.pRegister jet in core `s`
294−
295−`~/` XX
296−
297−`~<` Hint to product; applies arbitrary hint `p` to the product of `q`, which is computed beforehand
298−
299−`~>` Arbitrary hint `p` to `q`
300−
301−`~+` Memoize computation of `p`
302−
303−`~&` Printf
304−
305−`~=` Hint to avoid duplication
306−
307−`~?` PrintF if `q` is true
308−
309−`~!` Print type on compilation fail
310−
311−##### ! : Special runes
312−
313−`!_` Path and range in stack trace
314−
315−`!>` Produces a cell of both the type and value of `p` (called a `++vase`).
316−Useful for debugging.
317−
318−`!=` Show nock of `p`
319−
320−`!?` Enforce a Hon version restriction
321−
322−`!!` Crash
323−
324−
325−####Data types
326−
327−#####Strings
328−
329−`++tape` - List of chars. Used when you want to manipulate and interpolate text - `"[text]"`
330− See [list]() section for operations.
331−
332−`@t` - UTF-8 text; aka `++cord` - `'[text]'`
333− `++trip`: cord to string XX
334− `++taco`: cord to octet stream (for http requests) XX
335− `++slav`: parse cord to an atom of input odor XX
336−
337−`@ta` - Valid Hoon ASCII symbols - `~.[text]` + {`a-z`, `0-9`, `~`, `-`, `.`, `_`.}
338−`@tas` - Hoon identifier ASCII subset - `%` + `a-z`, `-` (not first), `1-9` (not first)
339−
340−XX Would love to add half a liine about the difference between cords and tapes.
341−
342−#####Numbers
343−
344−`@` - Generic atom (defaults to unsigned integer) - `42`
345−`@u` - Unsigned integer - `42`
346−`@sd` - Signed decimal - `-42`(-), `--42` see `++si` for operations
347−`@rd` - Single precision floating point - `.-42.75` (-), `.42.75` (+), see `++rd` for operations
348−
349−#####Other Important Atoms
350−`@da` - absolute date - `~~[year].[month].[date]..[hour].[minute].[second]..[fractionals]`
351− `++year`: `++date` to `@d` XX
352− `++yore`: `@d` to `++date` XX
353− note: year month day is mandatory, others are optional
354−`@dr` - relative date (timespan) - `~d[day].h[hour]m[minute].s[second]..[fractionals]`
355− note: every measurement optional.
356− `++add`: can add `@dr`s together XX
357− `++yell`: `@d` to `++tarp` XX
358−`@p` - phonemic base - `~[valid @p]`
359− `(scot %p [number])` prints a number as a `@p`
360−
361−#####Data structures
362−
363−######Tuples are made with the `:` runes and their irregular `[]` wide forms
364−
365− To construct, use [`[]`]() (irregular form of [`:` runes]()).
366−
367−`[3 'hello']`
368−
369−Special syntaxes:
370−
371−`~[1 2 3]` > `[1 2 3 ~]`
372−
373−`[1 2 3]~` > `[[1 2 3] ~]`
374−
375−`~[1 2 3]~` > `[[1 2 3 ~] ~]`
376−
377−######Autocons
378−
379−To eliminate need for excess `[]`, tuples automatically group to
380−the right:
381−
382−`[1 [2 [3 ~]]]` == `[1 2 3 ~]`
383−
384−######pair, trel, quad put faces on tuples
385−
386−``=+ a=`(pair term cord)`[%h 'j']`` > `[p=%h q='j']`
387−
388−Faces allow you to access specific axes within your context:
389−
390−`p.a` > `%h` and `p:[p=%h q='j']` > `%h`
391−
392−######Lists are null-terminated and have faces of `i` and `t`
393−
394−- Definition:
395−
396−`++ list |* a=_,* :: null-term list
397− $|(~ [i=a t=(list a)]) ::
398−`
399−
400−- Constructor: `++limo` makes a list out of a null terminated tuple.
401−
402−`(limo [67 55 201 ~])` > `[i=67 t=[i=55 t=[i=201 t=~]]]`
403−
404−``(list ,@t)`(list ,@)\`~[67 55] > <|C 7|>``
405−
406−- Operations:
407−
408−`++weld`: concatenate
409−`++scag`: slice up to (and including) index number args: (index, list)
410−`++slag`: slice list after index, args: (index, list)
411−`++turn`: map over list, args: (list, function)
412−`++reel`: right fold args: (list, function)
413−`++roll`: left fold args: (list, function)
414−`++sort`: quicksort, args: (list, comparator-function)
415−
416−######Map
417−
418−- Definition:
419−
420−` ++ map |* [a=_,* b=_,*] :: associative tree
421− $|(~ [n=[p=a q=b] l=(map a b) r=(map a b)]) ::
422−`
423−
424−- Constructor: `++mo` produces a map of key-val pairs from left-right cell pairs of a list
425−
426−`
427− ~zod/try=> (mo \`(list ,[@t *])\`[[a 1] [b 2] ~])
428− {[p=a q=1] [p=b q=2]}
429−`
430−
431−- Operations: contained within the `++by` core
432−
433−`++by` accepts a map, then we use `%~` to pull the desired arm, which we then
434−pass the remainder of the arguments
435−
436−`
437−> =m (mo \`(list ,[@t *])\`[['a' 1] ['b' 2] ~])
438−> (~(got by m) 'a')
439−1
440−`
441−
442−`+-all:by`: logical 'AND'
443−`+-any:by`: logical 'OR'
444−`+-del:by`: delete at key
445−`+-dig:by`: axis of key
446−`+-gas:by`: concatenate: insert a list of key-value pairs into map
447−`+-get:by`: pull out value at key as a unit
448−`+-got:by`: assert: pull value at key, crash if key doesn't exist
449−`+-has:by`: check if key exists
450−`+-int:by`: intersection: if keys match, use value from `b`
451−`+-put:by`: add key value pair
452−`+-rep:by`: fold over map
453−`+-run:by`: 'map' over map
454−`+-tap:by`: convert map to list
455−`+-uni:by`: produce union between keys; if both share keys, use value from `a`
456−`+-urn:by`: 'map', with key included with value as input to mapping function
457−`+-wyt:by`: produce depth of tree of map
458−
459−######Set
460−
461−- Definition:
462−
463−`
464− ++ set |* a=_,* :: set
465− $|(~ [n=a l=(set a) r=(set a)]) ::
466−`
467−
468−- Constructor: `++sa`
469−
470−`
471− ~zod/try=> (sa \`(list ,@)\`[1 2 3 4 5 ~])
472− {5 4 1 3 2}
473−`
474−
475−- Operations: contained within the `++in` core
476−
477−The `++in` core accepts a set, then we use `%~` to pull desired operation out
478−of it, which we then pass the remainder of the arguments.
479−
480− > =a (~(gas in `(set ,@t)`~) `(list ,@t)`[`a` `b` `c` ~])
481− > (~(has in a) `a`)
482− %.y
483−
484−
485−`+-all:in`: logical 'AND'
486−`+-any:in`: logical 'OR'
487−`+-del:in`: delete val at key
488−`+-dif:in`: difference between sets
489−`+-dig:in`: produce axis `b` in set
490−`+-gas:in`: concatenate: insert elements of list `b` into set
491−`+-has:in`: check if element exists in set
492−`+-int:in`: intersection
493−`+-put:in`: add an element to set
494−`+-rep:in`: fold over set
495−`+-tap:in`: convert set to list
496−`+-uni:in`: produces the union between two sets
497−`+-wyt:in`: Produces the number of elements in set
498−
499−#####Addressing within nouns
500−
501−There are several ways you can address an axes of a noun:
502−
503−1. `[face].[variable-name]`
504−
505−2. `-.+.+.a`: 'the head, within the tail of the tail of `a`.'
506−
507−Can also intersperse faces: `+.a.b` reads 'the tail of `a` within `b`.
508−
509−3. `->+.a`: 'tail within the head of the head of `a`.'
510−
511−Must start with either `-` (head) or `+` (tail), and then follow with either `<` (head) or `>` (tail), so
512−as to not repeat two symbols.
513−
514−4. `|[number].[var]` returns the elements that follow the nth element in a list
515−
516−5. `&[number]` returns the nth element in a list. Cannot return the last element.
517−
518−####Error messages
519−
520− i. hoon-how to generate the list of errors (Henry)
521−
522− ii. arvo
523− %a. Curtis
524− %b. Philip
525− %c. PHilip
526− %d. Curtis || Anton
527− %e. Anton
528− %f. Curtis || Anton
529− %g. Curtis || Anton
530−
531−
532−
docs/programming/hoon/cheat-sheets/odors.mddeleted−686
@@ -1,686 +0,0 @@
1−Odors
2−=====
3−
4−Overview
5−--------
6−
7−Since Everything in Hoon is a natural number, the interpreter needs to
8−know both how to render them and subject them to type enforcement.
9−Odors, which are just ASCII spans beginning with a `@`, carry all of the
10−information necessary for the interpreter to do this. For instance, the
11−interpreter knows to render an atom of odor `@t` as UTF-8 text.
12−
13−The span composing the Odor consists of two parts: a lowercase prefix
14−carrying type information, and an upper-case suffix containing
15−information about its size. The prefix is a taxonomy that grows more
16−specific to the right. For example, atoms of the odor `@ta` are URL-safe
17−ASCII text, and Atoms of the odor `@tas` are the more specific subset of
18−ASCII text that is acceptable in hoon.
19−
20−The general principle of type enforcement is that atoms change freely
21−either up or down the taxonomy, but not across. You can treat a `@tas`
22−as a `@t`, as in a strong type system; but you can also treat a `@t` as
23−a `@tas`, or an `@` as anything. However, passing a `@t` to a function
24−that expects an `@ux` is a type error.
25−
26−XXDIAGRAMXX
27−
28−For example, you can cast a `@t` to a `@tas`, or vice-versa:
29−
30− ~zod/try=> =a `@t`'permitted'
31− ~zod/try=> a
32− 'permitted'
33− ~zod/try=> `@tas`a
34− %permitted
35−
36−However, you cannot pass a `@ux` to a function that expects a `@t`
37−without casting it to a `@` first:
38−
39− ~zod/try=> (|=(a=@t [%foo a]) 0x20)
40− ! type-fail
41− ! exit
42− ~zod/try=> =a 0x21
43− ~zod/try=> (|=(a=@t [%foo a]) `@t`a)
44− [%foo '!']
45−
46−Note that when explicitly casting a `@ux` to a `@t`, the interpreter
47−automatically casts the `@ux` to a `@` first.
48−
49−Comprehensive list of the Hoon Odors
50−------------------------------------
51−
52− @c UTF-32 codepoint
53− @d date
54− @da absolute date
55− @dr relative date (ie, timespan)
56− @f yes or no (inverse boolean)
57− @n nil
58− @p phonemic base
59− @r IEEE floating-point
60− @rd double precision (64 bits)
61− @rh half precision (16 bits)
62− @rq quad precision (128 bits)
63− @rs single precision (32 bits)
64− @s signed integer, sign bit low
65− @sb signed binary
66− @sd signed decimal
67− @sv signed base32
68− @sw signed base64
69− @sx signed hexadecimal
70− @t UTF-8 text (cord)
71− @ta ASCII text (span)
72− @tas ASCII symbol (term)
73− @u unsigned integer
74− @ub unsigned binary
75− @ud unsigned decimal
76− @uv unsigned base32
77− @uw unsigned base64
78− @ux unsigned hexadecimal
79−
80−Odor Size Suffixes
81−------------------
82−
83−The suffix of an odor, if present, is a single upper-case character A-Z
84−`c`, which indicates the size of an atom. This is possible, because in
85−Hoon, a letter maps to an ASCII code number, thus a number.
86−
87−Size is specified in bits in the form of `1 << (c - 'A')` resp. `2^c`,
88−since most data aligns to the power of 2 or can be composed of such
89−blocks.
90−
91−The size of a block of size `N` can be calculated for example using
92−`(bex (sub 'N' 'A'))` in bits or `(div (bex (sub 'N' 'A')) 8)` in bytes.
93−
94−Thus, `@tD` is one UTF-8 byte (whatever that means) and `@tN` is 1
95−kilobyte or less of UTF-8.
96−
97−For reference:
98−
99− A 1 bit
100− B 2 bits
101− C 4 bits
102− D 1 byte
103− E 2 bytes
104− F 4 bytes
105− G 8 bytes
106− H 16 bytes
107− I 32 bytes
108− J 64 bytes
109− K 128 bytes
110− L 256 bytes
111− M 512 bytes
112− N 1K
113− O 2K
114− P 4K
115− Q 8K
116− R 16K
117− S 32K
118− T 64K
119− U 128K
120− V 256K
121− W 512K
122− X 1MB
123− Y 2MB
124− Z 4MB
125−
126−It is possible to construct an atom bigger than 4Mb in size, but the
127−type system would not be able to express an odor size for it.
128−
129−There is also the datatype `++bloq` to hold a to-the-power-of block size
130−(though it is just an alias for `@`).
131−
132−------------------------------------------------------------------------
133−
134−### @c
135−
136−UTF-32 codepoint
137−
138−Atoms of the odor `@c` represent Unicode text, constructed with a UTF-32
139−bytestream, with the lowest-significant bit first. Although we usually
140−use a UTF-8 bytestream, sometimes it's useful to build atoms of one or
141−more UTF-32 words.
142−
143−##### Forms
144−
145−`~-[text]`
146−
147−##### Examples
148−
149− ~zod/try=> ? ~-foo
150− ~-foo
151− @c
152− ~zod/try=> ~-i~2764.u
153− ~-i~2764.u
154− ~zod/try=> (tuft ~-i~2764.u)
155− 'i❤u'
156− ~zod/try=> `@ux`~-foo
157− 0x6f.0000.006f.0000.0066
158− ~zod/try=> `@ux`~-i~2764.u
159− 0x75.0000.2764.0000.0069
160− ~zod/try=> `@ux`(tuft ~-i~2764.u)
161− 0x75.a49d.e269
162−
163−------------------------------------------------------------------------
164−
165−### @d
166−
167−Date
168−
169−#### @da
170−
171−Absolute date
172−
173−Atoms of the odor `@da` represent absolute Urbit dates. Urbit dates
174−represent 128-bit chronological time, with 2\^64 seconds from the start
175−of the universe. For example, 2\^127 is 3:30:08 PM on December 5, AD
176−226. The time of day and/or second fragment is optional. As the last
177−example shows, BC times are also possible.
178−
179−##### Forms
180−
181−`~~[year].[month].[date]..[hour].[minute].[second]..[millisecond]`
182−
183−Note: the time of day and/or millisecond fragment is optional.
184−
185−##### Examples
186−
187− ~zod/try=> ~2014.1.1
188− ~2014.1.1
189− ~zod/try=> ? ~2014.1.1
190− ~2014.1.1
191− @da
192− ~zod/try=> ~2014.1.1..01.01.01
193− ~2014.1.1..01.01.01
194− ~zod/try=> ? ~2014.1.1..01.01.01
195− ~2014.1.1..01.01.01
196− @da
197− ~zod/try=> ~2014.1.1..01.01.01..1234
198− ~2014.1.1..01.01.01..1234
199− ~zod/try=> `@da`(bex 127)
200− ~226.12.5..15.30.08
201− ~zod/try=> `@da`(dec (bex 127))
202− ~226.12.5..15.30.07..ffff.ffff.ffff.ffff
203− ~zod/try=> `@ux`~2013.12.7
204− 0x8000.000d.2140.7280.0000.0000.0000.0000
205− ~zod/try=> `@ux`~2013.12.7..15.30.07
206− 0x8000.000d.2141.4c7f.0000.0000.0000.0000
207− ~zod/try=> `@ux`~2013.12.7..15.30.07..1234
208− 0x8000.000d.2141.4c7f.1234.0000.0000.0000
209− ~zod/try=> `@ux`~2013.12.7..15.30.07..1234
210− 0x8000.000d.2141.4c7f.1234.0000.0000.0000
211−
212−------------------------------------------------------------------------
213−
214−#### @dr
215−
216−Relative date (ie, timespan)
217−
218−Atoms of the odor `@dr` atoms represent basic time intervals in
219−milliseconds. There are no `@dr` intervals under a second or over a day
220−in length.
221−
222−##### Forms
223−
224−`~d[day].h[hour]m[minute].s[second]..[fractionals]`
225−
226−Note: Every measurement is optional, so long as those that are present
227−are in order. The largest measurement is preceded by a `~`.
228−
229−##### Examples
230−
231− ~zod/try=> ~d1.h19.m5.s29
232− ~d1.h19.m5.s29
233− ~zod/try=> ? ~d1.h19.m5.s29
234− ~d1.h19.m5.s29
235− @dr
236− ~zod/try=> `@dr`(div ~s1 1.000)
237− ~.s0..0041.8937.4bc6.a7ef
238− ~zod/try=> ~d1.h19.m5.s29..0041
239− ~d1.h19.m5.s29..0041
240− ~zod/try=> `@ux`~s1
241− 0x1.0000.0000.0000.0000
242− ~zod/try=> `@ux`~m1
243− 0x3c.0000.0000.0000.0000
244− ~zod/try=> `@dr`(div ~d1 5)
245− ~h4.m48
246− ~zod/try=> (div ~m1 ~s1)
247− 60
248− ~zod/try=> (div ~h1 ~m1)
249− 60
250− ~zod/try=> (div ~h1 ~s1)
251− 3.600
252− ~zod/try=> (div ~d1 ~h1)
253− 24
254− ~zod/try=> `@da`(add ~2013.11.30 ~d1)
255− ~2013.12.1
256−
257−------------------------------------------------------------------------
258−
259−#### @f
260−
261−Loobean(inverse boolean)
262−
263−Atoms of the odor `@f` represent loobeans, where `0` is yes and `1` is
264−no. Loobeans are often represented in their cubic and runic forms shown
265−below.
266−
267−##### Forms
268−
269−`0`, `1` as numbers. `%.y`, `%.n` as [`%cube`]()s. `&`, `|` as short
270−forms.
271−
272−##### Examples
273−
274− ~zod/try=> `@ud`.y
275− 0
276− ~zod/try=> ? .y
277− %.y
278− {%.y %.n}
279− ~zod/try=> `@ud`.n
280− 1
281− ~zod/try=> .y
282− %.y
283− ~zod/try=> &
284− %.y
285− ~zod/try=> |
286− %.n
287−
288−------------------------------------------------------------------------
289−
290−### @n
291−
292−Nil
293−
294−Atoms of the odor `@n` indicate an absence of information, as in a list
295−terminator. The only value is `~`, which is just `0`.
296−
297− ~zod/try=> ? ~
298− ~
299− %~
300− ~zod/try=> `@ud`%~
301− 0
302− ~zod/try=> `@ud`~
303− 0
304−
305−------------------------------------------------------------------------
306−
307−### @p
308−
309−Phonemic base
310−
311−Atoms of `@p` are primarily used to represent ships names, but they can
312−be used to optimize any short number for memorability. For example, it
313−is great for checksums.
314−
315−##### Forms
316−
317−`~[phonemic]`
318−
319−Every syllable is a byte. Pairs of two bytes are separated by `-`, and
320−phrases of four pairs are separated by `--`.
321−
322− ~zod/try=> ~pasnut
323− ~pasnut
324− ~zod/try=> ? ~pasnut
325− ~pasnut
326− @p
327− ~zod/try=> `@p`0x4321
328− ~pasnut
329− ~zod/try=> `@p`0x8765.4321
330− ~famsyr-dirwes
331− ~zod/try=> `@p`0x8766.4321
332− ~lidlug-maprec
333− ~zod/try=> `@p`(shaf %foo %bar)
334− ~ralnyl-panned-tinmul-winpex--togtux-ralsem-lanrus-pagrup
335−
336−------------------------------------------------------------------------
337−
338−### @r
339−
340−IEEE floating-points
341−
342−Hoon does not yet support floating point, so these syntaxes don't work
343−yet. But the syntax for a single-precision float is the normal English
344−syntax, with a `.` prefix:
345−
346−------------------------------------------------------------------------
347−
348−### @s
349−
350−Signed integer, sign bit low
351−
352−Without finite-sized integers, the sign extension trick obviously does
353−not work. A signed integer in Hoon is a different way to use atoms than
354−an unsigned integer; even for positive numbers, the signed integer
355−cannot equal the unsigned.
356−
357−The prefix for a negative signed integer is a single `-` before the
358−unsigned syntax. The prefix for a positive signed integer is `--`. The
359−least significant represents the sign. The representation is similar to
360−a folded number line.
361−
362−#### @sb
363−
364−Signed binary
365−
366−Atoms of the odor `@sb` represent signed binary numbers.
367−
368−#### Forms
369−
370−`-0b[negative_binary]` `--0b[postive_binary]`
371−
372−#### Examples
373−
374− ~zod/try=> ? -0b1
375− -0b1
376− @sb
377− ~zod/try=> `@sd`-0b1
378− -1
379− ~zod/try=> `@sd`--0b1
380− --1
381− ~zod/try=> `@sd`--0b11
382− --3
383− ~zod/try=> `@sb`(sum:si -0b10 -0b10)
384− -0b100
385−
386−------------------------------------------------------------------------
387−
388−#### @sd
389−
390−Signed decimal
391−
392−Atoms of odor `@sd` represent signed decimal numbers.
393−
394−#### Forms
395−
396−`-[negative[decimal]()]` `--[postive_[decimal]()]`
397−
398−#### Examples
399−
400− ~zod/try=> -234
401− -234
402− ~zod/try=> ? -234
403− -234
404− @sd
405− ~zod/try=> ? --234
406− --234
407− @sd
408− ~zod/try=> (sum:si -234 --234)
409− --0
410−
411−------------------------------------------------------------------------
412−
413−#### @sv
414−
415−Signed base32
416−
417−Atoms of odor `@sv` represent signed base32 numbers.
418−
419−##### Forms
420−
421−`-0v[negative_base32]` The digits are, in order, `0-9`, `a-v`.
422−`--0v[positive_base32]`
423−
424−##### Examples
425−
426− ~zod/try=> -0vv
427− -0vv
428− ~zod/try=> ? -0vv
429− -0vv
430− @sv
431− ~zod/try=> --0vb
432− --0vb
433− ~zod/try=> `@sd`-0vv
434− -31
435− ~zod/try=> `@sd`--0vb
436− --11
437− ~zod/try=> `@sd`(sum:si -0vv --0vb)
438− -20
439−
440−------------------------------------------------------------------------
441−
442−#### @sw
443−
444−Signed base64
445−
446−Atoms of odor `@sw` represent base64 numbers.
447−
448−##### Forms
449−
450−`-0w[negative_base64]` The digits are, in order, `0-9`, `a-z`,
451−`A-Z`,`-`, and `~`. `--0w[positive_base64]` The digits are, in order,
452−`0-9`
453−
454−##### Examples
455−
456− ~zod/try=> -0w--
457− -0w--
458− ~zod/try=> ? -0w--
459− -0w--
460− @sw
461− ~zod/try=> `@sd`(sum:si -0w-A -0w--)
462− -8.034
463−
464−#### @sx
465−
466−Signed hexadecimal
467−
468−Atoms of odor `@sx` represent signed hexadecimal numbers.
469−
470−##### Forms
471−
472−`-[negative_hexadecimal]` `--[positive_hexadecimal]`
473−
474−##### Examples
475−
476− ~~zod/try=> -0x0
477− --0x0
478− ~zod/try=> `@sd`--0x17
479− --23
480− ~zod/try=> `@ux`(bex 20)
481− 0x10.0000
482− ~zod/try=> 0x10. 0000
483− 0x10.0000
484− ~zod/try=> `@sd`(sum:si --0x17 -0x0)
485− --23
486− ~zod/try=> `@sd`(sum:si --0x17 -0xa)
487− --13
488−
489−------------------------------------------------------------------------
490−
491−### @t
492−
493−UTF-8 text (cord)
494−
495−Atoms of the odor `@t` represent a
496−[cord](http://en.wikipedia.org/wiki/Rope_data_structure), sequence of
497−UTF-8 bytes, LSB first. It is sometimes called a cord.
498−
499−##### Forms
500−
501−`~~[text]` `'[text]'`
502−
503−##### Examples
504−
505− ~zod/try=> ~~foo
506− 'foo'
507− ~zod/try=> ? 'foo'
508− 'foo'
509− @t
510− ~zod/try=> ? ~~foo
511− 'foo'
512− @t
513−
514−------------------------------------------------------------------------
515−
516−#### @ta
517−
518−ASCII text (span)
519−
520−Atoms of the odor `@ta` represent the ASCII text subset used in hoon
521−literals: `a-z`, `0-9`, `~`, `-`, `.`, `_`.
522−
523−##### Forms
524−
525−`~.[text]` There are no escape sequences.
526−
527−##### Examples
528−
529− ~zod/try=> ~..asdf
530− ~..asdf
531− ~zod/try=> ? ~.asdf
532− ~.asdf
533− @ta
534− ~zod/try=> `@t`~.asdf
535− 'asdf'
536−
537−------------------------------------------------------------------------
538−
539−#### @tas
540−
541−ASCII symbol (term)
542−
543−Atoms of `@tas` represent [`++term`]()s, the most exclusive text odor.
544−The only characters permitted are lowercase ASCII, except as the first
545−or last character, and 0-9, except as the first character.
546−
547−##### Forms
548−
549−`%[text]` This means a term is always [cubical]().
550−
551−##### Examples
552−
553− ~zod/try=> %dead-fish9
554− %dead-fish9
555− ~zod/try=> -:!>(%dead-fish9)
556− [%cube p=271.101.667.197.767.630.546.276 q=[%atom p=%tas]]
557−
558−------------------------------------------------------------------------
559−
560−### @u
561−
562−Unsigned integer
563−
564−------------------------------------------------------------------------
565−
566−#### @ub
567−
568−Unsigned binary
569−
570−Atoms of the odor `@ub` represent unsigned binary numbers.
571−
572−#### Forms
573−
574−`0b[number]` Numbers are least-significant bit first.
575−
576−##### Examples
577−
578− ~zod/try=> `@`0b1
579− 1
580− ~zod/try=> ? 0b1
581− 0b1
582− @ub
583− ~zod/try=> `@`0b10
584− 2
585− ~zod/try=> `@`0b100
586− 4
587−
588−------------------------------------------------------------------------
589−
590−#### @ud
591−
592−Unsigned decimal
593−
594−Atoms of `@ud` represent unsigned decimal numbers. It is the default
595−print format for both `@u` and and `@u`, namely unsigned numbers with no
596−printing preference, as well as opaque atoms.
597−
598−##### Forms
599−
600−Numbers of more than three digits must be delimited by `.`s. Whitespace
601−and linebreaks can appear between the dot and the next group.
602−
603− ~zod/try=> 0
604− 0
605− ~zod/try=> 19
606− 19
607− ~zod/try=> ? 19
608− 19
609− @ud
610− ~zod/try=> 1.024
611− 1.024
612− ~zod/try=> 65.536
613− 65.536
614− ~zod/try=> (bex 20)
615− 1.048.576
616−
617−------------------------------------------------------------------------
618−
619−#### @uv
620−
621−Unsigned base32
622−
623−Atoms of the odor `@uv` represent unsigned base64 numbers.
624−
625−##### Forms
626−
627−`0v[number]` The digits are, in order, `0-9`, `a-v`.
628−
629−##### Examples
630−
631− ~zod/try=> `@ud`0vv
632− 31
633− ~zod/try=> ? 0vv
634− 0vv
635− @uv
636− ~zod/try=> `@ud`(add 0vv 0v9)
637− 40
638−
639−------------------------------------------------------------------------
640−
641−#### @uw
642−
643−Unsigned base64
644−
645−##### Forms
646−
647−`ow[number]` The digits are, in order, `0-9`, `a-z`, `A-Z`,`-`, and `~`.
648−
649−##### Examples
650−
651− ~zod/try=> 0w~
652− 0w~
653− ~zod/try=> ? 0w~
654− 0w~
655− @uw
656− ~zod/try=> `@uv`(add 0w~ 0wZ)
657− 0v3s
658− ~zod/try=> `@ud``@uv`(add 0w~ 0wZ)
659− 124
660−
661−------------------------------------------------------------------------
662−
663−#### @ux
664−
665−Unsigned hexadecimal
666−
667−Atoms of the odor `@ux` represent hexadecimal numbers.
668−
669−##### Forms
670−
671−`0x`number. Numbers with more than four digits must be delimited by
672−`.`s. Hex digits are lowercase only.
673−
674− ~zod/try=> 0x0
675− 0x0
676− ~zod/try=> ? 0x0
677− 0x0
678− @ux
679− ~zod/try=> `@ud`0x17
680− 23
681− ~zod/try=> `@ux`(bex 20)
682− 0x10.0000
683− ~zod/try=> 0x10. 0000
684− 0x10.0000
685−
686−------------------------------------------------------------------------
docs/programming/hoon/cheat-sheets/pronunciation.mddeleted−68
@@ -1,68 +0,0 @@
1−Pronunciation
2−=============
3−
4−Overview
5−--------
6−
7−Hoon is a reserved-word-free
8−language - any text in the program is part of the program.
9−
10−We use so many of these ASCII glyphs that we like to be able
11−to read them out loud. A language is meant to be _said_. The
12−squiggles have conventional names, sort of, some of them easy to
13−say, others not so much. So we've renamed them:
14−
15− ace space
16− bar |
17− bas \
18− buc $
19− cab _
20− cen %
21− col :
22− com ,
23− doq "
24− dot .
25− fas /
26− gal <
27− gar >
28− hax #
29− hep -
30− kel {
31− ker }
32− ket ^
33− lus +
34− pam &
35− pat @
36− pel (
37− per )
38− sel [
39− sem ;
40− ser ]
41− sig ~
42− soq '
43− tar *
44− tec `
45− tis =
46− wut ?
47− zap !
48−
49−Memorizing these names seems like a burden, but it actually makes
50−communicating about hoon code a lot faster and easier. `bartis`
51−sounds a lot better than 'bar equals'.
52−
53−To pronounce a rune, concatenate the glyph names, stressing the
54−first syllable and softening the second vowel into a "schwa."
55−Hence, to say `~.`, say "sigdot." To say `|=`, say "bartis."
56−Which has an inevitable tendency to turn into "barts" - a sin
57−to be encouraged.
58−
59−There are a few runes with irregular special pronunciations:
60−
61− -- hephep phep
62− +- lushep slep
63− ++ luslus slus
64− == tistis stet
65− -> hepgar lark
66− -< hepgal lush
67− +> lusgar dark
68− +< lusgal dush
docs/programming/hoon/concepts.md+19−5
@@ -16,7 +16,7 @@ ones, which mean almost the same things. But why?
16
16
17## Motivation
17## Motivation
18
18
19−Hoon has no close relatives, and the normal jargon of programming
19+Hoon has no close relatives. The normal jargon of programming
20maps poorly onto its semantics. For example, although Hoon is a
20maps poorly onto its semantics. For example, although Hoon is a
21typed language, the term "type" is not formally defined in Hoon.
21typed language, the term "type" is not formally defined in Hoon.
22"Type" is a great word, but Hoon has three quite separate
22"Type" is a great word, but Hoon has three quite separate
@@ -64,12 +64,12 @@ scheme which maps an atom to a subtree. The whole noun is slot
64
64
65### `nock` (interpreter)
65### `nock` (interpreter)
66
66
67−Hoon compiles itself to the [Nock](nock) VM. Nock is a
67+Hoon compiles itself to the [Nock](../nock) VM. Nock is a
68Turing-complete, non-lambda combinator function. The function
68Turing-complete, non-lambda combinator function. The function
69takes a cell `{subject formula}`, and produces a noun `product`.
69takes a cell `{subject formula}`, and produces a noun `product`.
70
70
71To program in Hoon, this is all you need to know about Nock. But
71To program in Hoon, this is all you need to know about Nock. But
72−it's still fun and useful to [learn more](nock).
72+it's still fun and useful to [learn more](../nock).
73
73
74## Compilation concepts
74## Compilation concepts
75
75
@@ -81,6 +81,21 @@ expression (AST), and a `nock` is a Nock formula. `mint` accepts
81a subject type and a source expression; it produces a product type
81a subject type and a source expression; it produces a product type
82and an executable formula.
82and an executable formula.
83
83
84+Calculating the output type from the input type and the source
85+code is called "type inference." If you've used another typed
86+functional language, like Haskell, Hoon's type inference does the
87+same job but with less intelligence.
88+
89+Haskell infers backward and forward; Hoon only infers forward.
90+Hoon can't figure out the type of a noun from how you use it,
91+only from how you make it. Hoon can infer tail recursion, but
92+not head recursion.
93+
94+Low-powered type inference means you need more type annotations,
95+which makes your program more readable anyway. Also, the dumber
96+the compiler, the easier it is for a dumb human to understand
97+what the compiler is thinking.
98+
84### `twig` (expression)
99### `twig` (expression)
85
100
86A [`twig`](twig) is a Hoon AST node, the result of parsing a
101A [`twig`](twig) is a Hoon AST node, the result of parsing a
@@ -187,8 +202,7 @@ arm `foo`. If it finds a face, the product is a *leg*, or
187subtree of the subject. If it finds a core, it computes the arm
202subtree of the subject. If it finds a core, it computes the arm
188formula with that core as the subject.
203formula with that core as the subject.
189
204
190−A limb can also be a slot (tree address), like `+15`, which
205+A limb can also be a slot (direct tree address), like `+15`.
191−takes a leg directly.
192
206
193### `wing` (limb path)
207### `wing` (limb path)
194
208
docs/programming/hoon/demo.md+2−2
@@ -27,8 +27,8 @@ line is commented with its number:
27:moar(count (add 1 count)) :: 15
27:moar(count (add 1 count)) :: 15
28```
28```
29
29
30−Can you understand this code by just looking at it? Hopefully,
30+Can you understand this code by just looking at it? Maybe.
31−but let's explain it anyway.
31+But let's explain it anyway.
32
32
33Hoon is a functional language. FizzBuzz is usually defined as a
33Hoon is a functional language. FizzBuzz is usually defined as a
34side effect, but Hoon has no side effects. This code will
34side effect, but Hoon has no side effects. This code will
docs/programming/hoon/examples.md+2−1
@@ -1,6 +1,7 @@
1---
1---
2−sort: 8
2+sort: 9
3title: Examples
3title: Examples
4+next: true
4---
5---
5
6
6# Examples
7# Examples
docs/programming/hoon/library.md+3−4
@@ -1,9 +1,8 @@
1---
1---
2−sort: 12
2+sort: 11
3−title: Standard Library
3+title: Library
4---
4---
5
5
6−Library
6+# Library
7−========
8
7
9<list dataPreview="true" titlesOnly="true"></list>
8<list dataPreview="true" titlesOnly="true"></list>
docs/programming/hoon/mint.mddeleted−27
@@ -1,27 +0,0 @@
1−---
2−sort: 6
3−next: true
4−Title: Compiler
5−---
6−
7−# Compiler: `mint`
8−
9−`mint` is the Hoon compiler. It maps a cell `{subject/span
10−source/twig}` to a cell `{product/span formula/nock}`, where
11−`span` is a type, `twig` is a compiled expression, and `nock` is
12−a Nock formula.
13−
14−Calculating the output type from the input type and the source
15−code is called "type inference." If you've used another typed
16−functional language, like Haskell, Hoon's type inference does the
17−same job but with less intelligence.
18−
19−Haskell infers backward and forward; Hoon only infers forward.
20−Hoon can't figure out the type of a noun from how you use it,
21−only from how you make it. Hoon can infer tail recursion, but
22−not head recursion.
23−
24−Low-powered type inference means you need more type annotations,
25−which makes your program more readable anyway. (Also, the dumber
26−the compiler, the easier it is for a dumb human to understand
27−what the compiler is thinking.)
docs/programming/hoon/noun.mddeleted−37
@@ -1,37 +0,0 @@
1−---
2−sort: 4
3−next: true
4−title: Data model: noun
5−---
6−
7−# Data model: `noun`
8−
9−A value in Hoon is called a `noun`. A noun is either a unsigned
10−integer of any size (`atom`), or an ordered pair of any two
11−nouns (`cell`). In other words, a noun is a binary tree whose
12−leaves are unsigned integers.
13−
14−Nouns are a Nock concept; there is no Nock syntax; so there is no
15−general noun syntax. But nouns are usually written with square
16−brackets associating right; `[a b c]` means `[a [b c]]`. In Hoon
17−we also see `{a b c}`, a constructor (`mold`) for `[a b c]`.
18−
19−Nouns are almost like Lisp's S-expressions, but S-expressions
20−have dynamic type tags in atoms; the difference between a symbol
21−and an integer, for instance, is dynamic type. Lisp needs this
22−dynamic type because it doesn't expect a static type system.
23−
24−For the same reason, nouns tend to be tuple-centric where Lisp is
25−list-centric. Lisp `(a b c)` as a noun is `[a b c 0]`; Nock `[a
26−b c]` is Lisp `(a . b . c)`.
27−
28−Nouns are immutable and acyclic. A naive implementation uses
29−reference counting and needs no tracing GC. There is no test for
30−pointer equality as in Lisp. But indirect nouns have a lazily
31−computed short hash, so nonduplicates have O(1) comparison cost.
32−
33−All kinds of atomic values can be and are stored as atoms:
34−unsigned integers, signed integers (with sign bit low), dates,
35−floats, UTF-8 strings (LSB first), even whole files. Again,
36−a static type system is essential; an atom is not usable or even
37−printable if we don't know what it means.
docs/programming/hoon/philosophy.md+15−19
@@ -13,10 +13,10 @@ Hoon's design goal is to support higher-order typed functional
13programming without category theory, formal logic, or other
13programming without category theory, formal logic, or other
14interesting math. The reasoning: (a) a programming language is a
14interesting math. The reasoning: (a) a programming language is a
15user interface for programmers; (b) most programmers are not very
15user interface for programmers; (b) most programmers are not very
16−good at math. Hoon is not quite as expressive as Haskell, though
16+good at math.
17−fairly close.
18
17
18+Hoon is not quite as expressive as Haskell, though fairly close.
19−Good Hoon style varies from good Haskell style. Hoon encourages
19+But good Hoon style isn't good Haskell style. Hoon encourages
20coders to use higher-order programming as little as possible --
20coders to use higher-order programming as little as possible --
21again, simply for UI reasons. For example, multiple arguments
21again, simply for UI reasons. For example, multiple arguments
22are curried by default in Haskell and tupled by default in Hoon.
22are curried by default in Haskell and tupled by default in Hoon.
@@ -25,22 +25,18 @@ a functional language." The power of Haskell, or close, is there
25when we really need it. But we try not to swat flies with it.
25when we really need it. But we try not to swat flies with it.
26
26
27Hoon is objectively simple: its complexity is bounded by the size
27Hoon is objectively simple: its complexity is bounded by the size
28−of the compiler, about 3000 lines of Hoon. This is split about
28+of the compiler, about 3000 lines of Hoon. This is split evenly
29−halfway half between frontend (parsing and macro expansion) and
29+between frontend (parsing and macro expansion) and backend (code
30−backend (code generation and type inference).
30+generation and type inference).
31−
31+
32+Compared to most languages, Hoon has a heavier front end (more
33+complex syntax) and a lighter back end (less complex semantics).
32−This parser-heavy ratio reflects the belief that our brains are
34+This ratio reflects the belief that our brains are better than
33−better than everyone thinks at learning languages (symbols and/or
35+everyone thinks at learning languages (symbols and/or grammars),
34−grammars), and worse at learning abstractions (proofs and/or
36+and worse at learning abstractions (proofs and/or algorithms).
35−algorithms). At first glance, Hoon may look gnarly (though its
37+At first glance, Hoon may look gnarly (though its squiggles are
36−squiggles are more structured than most ASCII-heavy languages).
38+more structured than most ASCII-heavy languages). But there's
37−But there's less than you might expect under the hood.
39+less than you might expect under the hood.
38−
39−(Hoon has simple principles and a lot of details. To keep the
40−details from getting overwhelming, we start out learning a
41−simplified subset called Core Hoon. Note that some of the
42−internal structures we show are simplified to match the subset.
43−These simplifications are corrected in the Advanced section.)
44
40
45Keeping the Hoon-to-Nock mapping straightforward is a priority.
41Keeping the Hoon-to-Nock mapping straightforward is a priority.
46Very roughly, Hoon is to Haskell as C is to Pascal. Pascal tries
42Very roughly, Hoon is to Haskell as C is to Pascal. Pascal tries
docs/programming/hoon/syntax.mdnew file+367
@@ -0,0 +1,367 @@
1+---
2+sort: 4
3+next: true
4+title: Syntax
5+---
6+
7+# Hoon syntax
8+
9+Hoon's semantics are simple, but unusual. Hoon's syntax is
10+complex, and unusual. Sorry.
11+
12+## Motivation
13+
14+An excuse: the normal human brain doesn't have hardware support
15+for math, but it does have hardware support for syntax. Learning
16+math is harder than it looks. Learning syntax is easier.
17+
18+An explanation: the Hoon syntax is trying to solve three serious
19+problems in functional syntax design. These are *terminator
20+piles*, *indentation creep*, and *feature/label confusion*.
21+
22+## Terminator piles
23+
24+*Terminator piles* are like Lisp's stacks of right parenthesess.
25+Significant whitespace solves this problem and creates others.
26+
27+Hoon has no terminator piles. Except for a 1-space / more-space
28+distinction, it has no significant whitespace.
29+
30+## Indentation creep
31+
32+*Indentation creep* is a problem caused by indentation conventions
33+where the indentation point is a function of expression tree
34+depth. It's true that short functions are better than long ones,
35+but long ones sometimes need to be written.
36+
37+A procedural block has a backbone of statements which flows
38+straight down. Most expressions are flat and of limited depth.
39+With some bulging, a long function flows *down* the page.
40+
41+A functional language lacks the expression/statement distinction.
42+So a long function means a deep tree. Given normal indentation
43+conventions, a long function wants to flow *down and across*.
44+This *diagonal* shape fits poorly into most editor windows.
45+
46+Thanks to backstep indentation (see below), Hoon programs are
47+shaped more or less like procedural programs.
48+
49+## Feature/label confusion
50+
51+*Feature/label confusion* is any syntax which makes it hard for
52+the eye to tell whether a token on the screen is a feature of the
53+language, or a label in the program. For example, in Lisp a
54+special form has the same syntax as a function call.
55+
56+The worst-case result of FLC is "DSL cancer". Every source file
57+is effectively written in its own domain-specific language. To
58+read a new file is to learn a new language -- "write-only code."
59+
60+A fixed reserved-word set, especially with syntax highlighting,
61+and especially with orthogonal grammar (in C, you don't write
62+`for(a b c)`), may not be too bad. User-level macros, operator
63+overloading, even excessive use of higher-order programming,
64+can all lead quickly to the tragedy of write-only code.
65+
66+Hoon has very weak FLC in keyword style, none in rune style.
67+It has no user-level macros or overloading. It does support
68+higher-order programming; write-only Hoon can certainly be
69+(and has been) written. But good Hoon style is to avoid it.
70+
71+# Design
72+
73+Because each twig stem has its own bulb, each has its own parser
74+rule. We'll describe these grammars as we go through the stems.
75+
76+But Hoon has a general syntax design with common principles and
77+regularities. We'll cover those here.
78+
79+## Glyphs and characters
80+
81+Hoon is a heavy punctuation user. To make ASCII great again,
82+we've mapped each punctuation glyph to a syllable:
83+
84+```
85+ace [1 space] gal < pal (
86+bar | gap [>1 space, nl] par )
87+bas \ gar > sel [
88+buc $ hax # sem ;
89+cab _ hep - ser ]
90+cen % kel { sig ~
91+col : ker } soq '
92+com , ket ^ tar *
93+doq " lus + tec `
94+dot . pam & tis =
95+fas / pat @ wut ?
96+zap !
97+```
98+
99+You don't need to memorize these glyph names, but it helps. Code
100+is often vocalized or subvocalized. "pal" is easier to say,
101+aloud or silently, then "left paren."
102+
103+Note that the list includes two separate whitespace forms: `ace`
104+for a single space, `gap` for 2+, comment or newline. Hoon
105+Besides `ace` versus `gap`, whitespace is not significant.
106+
107+Comments start with `::` and run to the end of the line. Hard
108+tab characters are illegal, and an 80-column right margin is
109+strongly encouraged. Really well-groomed Hoon uses a 55-column
110+code margin and puts a standard line comment at column 57.
111+
112+Hoon does not accept non-ASCII text in source files, except UTF-8
113+in quoted strings.
114+
115+## Tall and flat forms
116+
117+There are two kinds of Hoon expression syntax: *tall* and *flat*.
118+Most stems have both tall and flat forms. Tall twigs can contain
119+flat twigs, but not vice versa.
120+
121+Visually, a tall twig looks like a "statement" and a flat twig
122+like an "expression," preserving the attractive visual shape of
123+procedural code without the nasty side effects.
124+
125+## Regular and irregular forms
126+
127+Most stems have *regular forms*, which share a common design.
128+There is a regular flat form and a regular tall form; most stems
129+implement both. All tall forms are regular.
130+
131+Some twigs also have *irregular forms*, which follow no
132+principles at all. All irregular forms are flat.
133+
134+Some twigs (simple leafy ones) have *only* irregular forms.
135+
136+## Keywords versus runes
137+
138+A regular form starts with a *sigil*, which is either a
139+*keyword* or a *rune* -- at the programmer's choice.
140+
141+A *keyword* is `:` and then the stem label - eg, `:cons`.
142+
143+A *rune* is a pair of ASCII punctuation marks (a digraph) - eg,
144+`:-`. The first glyph in the rune indicates the category - eg,
145+`:` runes make cells. Runes can be pronounced by their glyphs or
146+by their stem -- for `:-`, you can say either "colhep" or "cons".
147+
148+Keywords may be less challenging for early learners. Rune style
149+is less cluttered and distracting for experienced programmers;
150+the system codebase is all in rune style. Beginners can start
151+with keywords and move to runes; start with runes and stick
152+with runes; or start with keywords and stick with keywords.
153+
154+Here's the FizzBuzz demo code, in idiomatic rune syntax. Compare
155+with the [original](../../demo).
156+
157+```
158+ |= end/atom
159+ =/ count 1
160+ |- ^- (list tape)
161+ ?: =(100 count) ~
162+ :_ $(count (add 1 count))
163+ ?: =(0 (mod count 15))
164+ "FizzBuzz"
165+ ?: =(0 (mod count 5))
166+ "Fizz"
167+ ?: =(0 (mod count 3))
168+ "Buzz"
169+ (text !>(count))
170+```
171+
172+## Tall regular form
173+
174+Tall regular form starts with the sigil, followed by a `gap`
175+(any whitespace except `ace`), followed by a bulb whose twigs are
176+separated by `gap`.
177+
178+There are four body subtypes: *fixed*, *running*, *jogging*, and
179+*battery*. Stems with a *fixed* number of subexpressions
180+self-terminate. For instance, `:if` has three subexpressions and
181+is self-terminating. Otherwise the twig is terminated by a
182+`gap`, then either `==` (*running* or *jogging*, most twigs) or
183+`--` (*battery*).
184+
185+The *running* body is a list of twigs. The *jogging* body is a
186+list of twig pairs, separated by a `gap`. The *battery* body is
187+a list of symbol-twig pairs, separated by a gap, prefixed by `++`
188+and then a gap.
189+
190+This definition is enough to parse. But the proper shape of the
191+whitespace gaps demands an informal convention.
192+
193+Whitespace design in Hoon is an art, not a science. It involves
194+both tall/flat mode switches and well-shaped gaps. (Hoon layout
195+could probably be done automatically with reasonable quality.
196+But it would at least take machine learning, not a rule engine.)
197+
198+There only two real *rules* in Hoon whitespace design: don't
199+go past 80 characters, and don't use (completely) blank lines.
200+Otherwise, if it looks good and is easy to read, it's good. But
201+the best way to learn the art is to do everything by convention
202+until you know what you're doing. Here are the conventions:
203+
204+### Conventions: *fixed*
205+
206+Bulbs with *fixed* fanout use "backstep" indentation, which slopes
207+backward and to the right by two spaces per line. The first
208+child is two spaces after the end of the sigil.
209+
210+Some *1-fixed*, *2-fixed*, *3-fixed* and *4-fixed* examples:
211+
212+```
213+|.
214+p
215+
216+=| p
217+q
218+
219+?: p
220+ q
221+r
222+
223+%^ p
224+ q
225+ r
226+s
227+```
228+
229+The hope of backstep indentation is that the heaviest twigs are
230+at the bottom, keeping code flow vertical rather than diagonal.
231+Alternate, reversing
232+
233+### Conventions: *running*
234+
235+A *running* bulb (a simple child list) puts the first child two
236+spaces after the end of the sigil, and the following children
237+straight down:
238+
239+A *running* example:
240+
241+```
242+:* p
243+ q
244+ r
245+ s
246+ t
247+==
248+```
249+
250+### Conventions: *jogging*
251+
252+A *jogging* bulb (a list of child pairs) is like a running bulb,
253+but backsteps the head of the pair above the tail. Most jogging
254+twigs start with a *fixed* sequence; the first jogging pair is
255+below and two steps backward from the last fixed child.
256+
257+There are two jogging conventions: *flat* (pair on one line) and
258+*tall* (pair split across lines).
259+
260+A *flat jogging* example (preceded by *1-fixed* `p`)
261+
262+```
263+?- p
264+ q r
265+ s t
266+ u v
267+==
268+```
269+
270+A *tall jogging* example (preceded by *1-fixed* `p`):
271+
272+```
273+?- p
274+ q
275+ r
276+ s
277+ t
278+ u
279+ v
280+==
281+```
282+
283+### Conventions: *battery*
284+
285+A *battery* bulb is a list of symbol-twig pairs, for the battery
286+of a core. A conventional example:
287+
288+```
289+|%
290+++ foo
291+ p
292+++ bar
293+ q
294+--
295+```
296+
297+## Flat regular form
298+
299+Flat regular form starts with the sigil, followed by `pal`
300+(`(`, left parenthesis), followed by a bulb whose subexpressions
301+are separated by `ace` (one space), followed by `par` (`)`, right
302+parenthesis).
303+
304+A twig in flat form, `:if`, `?:`, `{$if p/twig q/twig r/twig}`:
305+
306+```
307+:if(p q r)
308+
309+?:(p q r)
310+```
311+
312+The only exception is *jogging* bodies, in which subexpression
313+pairs are separated by commas:
314+
315+```
316+:make(foo bar 42, baz 55, moo 17)
317+```
318+
319+There is no flat regular form for *battery* bodies. Be tall.
320+
321+## Naming conventions
322+
323+Hoon does not enforce any rule on symbols, except that capitals
324+are not allowed (use kebab-case). However, a lot of system code
325+is written in using "lapidary" conventions that need explanation.
326+
327+Naming things is one of the hard problems in CS. Dodging this
328+problem is one of the reasons mathematicians use Greek letters,
329+not variable names. Meaningful names also interpose a verbal
330+interpretation, distracting at best and confusing at worst, on
331+the formula or algorithm. Greek letters are not *meaningful*,
332+but they are *memorable*. And their interpretation is defined by
333+the formula and nothing else.
334+
335+### Lapidary and ultralapidary
336+
337+In the *lapidary* naming style, labels are pronounceable
338+three-letter strings, usually CVC (consonant-vowel-consonant).
339+Sometimes they encode a mnemonic, but usually they are just
340+memorable. Labels are reused wherever the analogy seems
341+appropriate.
342+
343+In the *ultralapidary* naming style, labels are single letters,
344+starting in order of construction from `a`, or within a tuple
345+mold `p`. Hoon uses single-letter names for the same reason
346+Algol style languages pass arguments by order, rather than
347+keyword. Naming items by order makes sense when there are no
348+more than three or four; five is stretching it; six is too many.
349+
350+For example, when defining `add`, we want to name the operands
351+`a` and `b`. It's silly to call them `foo` and `bar`, let alone
352+`left-operand` and `right-operand`. The smaller the scale of an
353+algorithm, the simpler its names should be.
354+
355+### When in doubt, don't be lapidary
356+
357+This works in the other direction: namelessness doesn't scale.
358+Most normal code shouldn't use lapidary naming at all. (Everyone
359+agrees: there is *way* too much lapidary Hoon in Urbit.)
360+
361+Lapidary naming is only for *inherently simple code*: code that
362+both aspires to high elegance and clarity, and *is solving a
363+simple and elegant problem*.
364+
365+Given an ugly or complex problem, lapidary naming is a liability,
366+no matter the excellence of the programmer. When in doubt, use
367+long names and/or kebab-case.
docs/programming/hoon/troubleshooting.md+2−1
@@ -1,6 +1,7 @@
1---
1---
2−sort: 9
2+sort: 8
3title: Troubleshooting
3title: Troubleshooting
4+next: true
4---
5---
5
6
6# Troubleshooting
7# Troubleshooting
docs/programming/hoon/twig.md+12−8
@@ -1,13 +1,14 @@
1---
1---
2−sort: 7
2+sort: 6
3next: true
3next: true
4−title: Expressions: twig
4+title: Expressions
5---
5---
6
6
7−# Expression: `twig`
7+# Expressions
8
8
9+A Hoon expression is called a `twig`. A `twig` is an AST node:
9−A `twig` is an AST node: the noun that the Hoon compiler makes
10+the noun that the Hoon compiler makes when it parses a source
10−when it parses a source expression.
11+expression.
11
12
12The definition of `twig` is the definition of Hoon. So let's
13The definition of `twig` is the definition of Hoon. So let's
13define the syntax and semantics of Hoon, a twig at a time. But
14define the syntax and semantics of Hoon, a twig at a time. But
@@ -37,9 +38,12 @@ syntax and semantics; again, the difference is how we use it.
37
38
38Twigs are described as *mossy* (or *moldy*) and *seedy*; an
39Twigs are described as *mossy* (or *moldy*) and *seedy*; an
39example of X is the seedy form of X, a mold producing X is its
40example of X is the seedy form of X, a mold producing X is its
40−mossy form. For instance, `$foo` (mossy) is a mold whose product
41+mossy form.
41−is always `%foo` (seedy). (Obviously, seed is *yang* and moss is
42+
42−*yin*, so we can also say "yang foo" or "yin foo".)
43+For instance, `[%foo %bar]` is seedy: a twig producing the noun
44+`[7.303.014 7.496.034]`. `{$foo $bar}` is mossy: a twig
45+producing a function whose product is always `[7.303.014
46+7.496.034]`.
43
47
44## Twig categories
48## Twig categories
45
49
docs/programming/hoon/twig/atom.md+2−1
@@ -1,5 +1,6 @@
1---
1---
2−sort: 2
2+sort: 1
3+next: true
3---
4---
4
5
5# Atoms, constants, quasi-constants
6# Atoms, constants, quasi-constants
docs/programming/hoon/twig/bar-core.mdnew file+20
@@ -0,0 +1,20 @@
1+---
2+sort: 5
3+next: true
4+---
5+
6+# Cores (`|` runes)
7+
8+Core twigs are flow twigs. The compiler essentially pins a Nock
9+formula, or battery of formulas, to the subject.
10+
11+All `|` twigs are macros around `$core`. (See the `$core`
12+section in [`span`](../span) above.) `$core` uses the subject as
13+the payload of a battery, whose arms are compiled with the core
14+itself as the subject.
15+
16+## Twigs
17+
18+<list dataPreview="true" className="runes" linkToFragments="true"></list>
19+
20+<kids className="runes"></kids>
docs/programming/hoon/catalog/bar-core/cab-door.md → docs/programming/hoon/twig/bar-core/cab-door.mdrenamed

The content is the same.

docs/programming/hoon/catalog/bar-core/cen-core.md → docs/programming/hoon/twig/bar-core/cen-core.mdrenamed

The content is the same.

docs/programming/hoon/catalog/bar-core/dot-trap.md → docs/programming/hoon/twig/bar-core/dot-trap.mdrenamed

The content is the same.

docs/programming/hoon/catalog/bar-core/hep-loop.md → docs/programming/hoon/twig/bar-core/hep-loop.mdrenamed

The content is the same.

docs/programming/hoon/catalog/bar-core/tar-gill.md → docs/programming/hoon/twig/bar-core/tar-gill.mdrenamed

The content is the same.

docs/programming/hoon/catalog/bar-core/tis-gate.md → docs/programming/hoon/twig/bar-core/tis-gate.mdrenamed

The content is the same.

docs/programming/hoon/twig/buc-mold.mdnew file+45
@@ -0,0 +1,45 @@
1+---
2+sort: 7
3+next: true
4+---
5+
6+# Molds (`$` runes).
7+
8+A *mold* is a `gate` (function) that helps us build simple and
9+rigorous data structures. (In fact, since "mold" sounds nasty,
10+molds are often called "structures.")
11+
12+## Overview
13+
14+While Hoon can't check this property statically, a proper mold
15+is a *normalizer*: an idempotent function across all nouns. If
16+the sample of a gate has span `%noun`, and its body obeys the
17+constraint that for any x, `=((mold x) (mold (mold x)))`, it's a
18+rectifier and can be used as a mold.
19+
20+Twigs in the `$` family are macros designed for making molds.
21+But any Hoon twig may produce a mold. (This is why `moss` is a
22+synonym for `twig`).
23+
24+Many macros *bunt* a mold, producing `:per(mold $)`. This value,
25+simply the result of executing the gate on the default sample,
26+is a constant by definition and normally can be compiled as such.
27+The range of a mold (the span of its bunt) is called its *icon*.
28+
29+Molds have two uses: defining simple and rigorous structures, and
30+validating untrusted input data. Validation, though very
31+important, is a rare use case. Except for direct raw input,
32+it's generally a faux pas to rectify nouns at runtime -- or even
33+in userspace.
34+
35+As a structure definition, a mold has three common uses. One,
36+its bunt is a default value (such as the sample in a gate.) Two,
37+the product of some computation is cast to its icon, both
38+checking the type and regularizing it. Three, it's used as a
39+building block in other molds.
40+
41+## Twigs
42+
43+<list dataPreview="true" className="runes" linkToFragments="true"></list>
44+
45+<kids className="runes"></kids>
docs/programming/hoon/catalog/buc-mold/cab-shoe.md → docs/programming/hoon/twig/buc-mold/cab-shoe.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/cen-book.md → docs/programming/hoon/twig/buc-mold/cen-book.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/col-bank.md → docs/programming/hoon/twig/buc-mold/col-bank.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/hep-lamb.md → docs/programming/hoon/twig/buc-mold/hep-lamb.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/ket-bush.md → docs/programming/hoon/twig/buc-mold/ket-bush.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/pat-claw.md → docs/programming/hoon/twig/buc-mold/pat-claw.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/tis-coat.md → docs/programming/hoon/twig/buc-mold/tis-coat.mdrenamed

The content is the same.

docs/programming/hoon/catalog/buc-mold/wut-pick.md → docs/programming/hoon/twig/buc-mold/wut-pick.mdrenamed

The content is the same.

docs/programming/hoon/twig/call.mddeleted−121
@@ -1,121 +0,0 @@
1−---
2−sort: 7
3−---
4−
5−# Full make (`%` runes)
6−
7−We've already covered the irregular-only twigs `$wing` and
8−`$limb`. These are simple forms of the *invocation* family of
9−twigs, `%`, whose general form is `$make`, `%=`.
10−
11−## Regular forms
12−
13−The rune prefix is `%`. Suffixes: `=` for `:make`, `~` for
14−`:open`, `-` for `:call`, `+` for `:calt`, `^` for `:calq`, `*`
15−for `:calp`.
16−
17−### `:make`, `%=`, "centis", `{$make p/wing q/(list (pair wing twig))}`
18−
19−Syntax: *1-fixed*, then *jogging*.
20−
21−The product: `p`, modified by the change list `q`.
22−
23−If `p` resolves to a leg, `q` is a list of changes to that leg.
24−If `p` resolves to an arm, `q` is a list of changes to the core
25−containing that arm. We compute the arm on the modified core.
26−
27−### `:open`, `%~`, "censig", `{$open p/wing q/twig r/twig}`
28−
29−Syntax: *3-fixed*.
30−
31−Expands to:
32−
33−```
34− :pin q
35− :make(p.+2 +6 :per(+3 r))
36−```
37−
38−We pin `q`, making our subject `[q subject]`. We make arm `p` on
39−`q`, changing leg `6` to `r` (per the original subject).
40−
41−Wut? Why? `$open` is a general case of `$call`; see below.
42−
43−### `:call`, `%-`, "cenhep", `{$call p/twig q/twig}`/
44−
45−Syntax: *2-fixed*.
46−
47−Expands to: `:open($ p q)`.
48−
49−`$call` is a function call; `p` is the function (`gate`), `q` the
50−argument. `$call` is a special case of `$open`, and a gate is a
51−special case of a `door` (see the [core](../core) twigs).
52−
53−In a gate, the modified core has only one anonymous arm; in a
54−door it gets a full battery. Intuitively, a gate defines one
55−algorithm it can compute upon its sample, `+6`. A door defines
56−many such algorithms.
57−
58−In classical languages, doors correspond to groups of functions
59−with the same argument list, or at least sharing a prefix. In
60−Hoon, this shared sample is likely to be pulled into a door.
61−
62−### `:calt`, `%+`, "cenlus", `{$calt p/twig q/twig r/twig}`
63−
64−Syntax: *3-fixed*.
65−
66−Expands to: `:(call p [q r])`.
67−
68−### `:calq`, `%^`, "cenket", `{$cnkt p/twig q/twig r/twig s/twig}`
69−
70−Syntax: *4-fixed*.
71−
72−Expands to: `:(call p [q r s])`.
73−
74−### `:calp`, `%*`, "centar", `{$cntr p/twig q/(list twig)}`
75−
76−Syntax: *4-fixed*.
77−
78−Expands to: `:(call p [q])`.
79−
80−## Irregular forms
81−
82−### Classic call, `(p q r s)`
83−
84−Translation:
85−
86−```
87−(p) :per(p $)
88−(p q) :call(p q)
89−(p q r s) :call(p [q r s])
90−```
91−
92−### Modified wing, `p.q(r s, t u, v w)`
93−
94−Translation:
95−
96−```
97−p.q(r s, t u, v w) :make(p.q r s, t u, v w)
98−```
99−
100−### Anonymous recursion, `:moar*`.
101−
102−Translation:
103−
104−```
105−:moar $
106−:moar(a b, c d, e f) $(a b, c d, e f)
107−:moarr ^$
108−:moarrrr ^^^$
109−```
110−
111−`:moar` has tall and wide form like a regular stem, though it has
112−no rune and is not a regular stem.
113−
114−`$` is a label like any other. But loops, gates, and traps all
115−hardcode this label. `$` thus implies recursing back to the
116−nearest `:loop` (`|-)`, `:gate` (`|=`), or `:trap` (`|.`). (Or
117−`^$` for the second nearest, `^^$` for the third, etc.
118−
119−`$` *seems* like a language primitive (eg, Clojure's `recur`), so
120−we made it look like one. Keyword enthusiasts and cats who love
121−cheeseburgers will appreciate `:moar`. Others can use `$`.
docs/programming/hoon/twig/cast.mddeleted−53
@@ -1,53 +0,0 @@
1−---
2−sort: 10
3−---
4−
5−# Type manipulation (`^` runes).
6−
7−`$cast`, `$like`, and `$name` let us adjust spans without
8−violating type constraints.
9−
10−The `nest` algorithm which tests span subtyping is conservative;
11−it never allows invalid nests, it sometimes rejects valid nests.
12−
13−## Regular forms
14−
15−### `:like`, `^+`, "ketlus", `{$like p/twig q/twig}`
16−
17−Syntax: *2-fixed*.
18−
19−The product is the formula of `q` with the span of `p`, provided
20−nouns within the span of `q` can be shown to nest within the span
21−of `p`.
22−
23−### `:cast`, `^-`, "ketlus", `{$like p/moss q/twig}`
24−
25−Syntax: *2-fixed*.
26−
27−Expands to: `:like($.p q)`.
28−
29−`$like` is a typecheck by example; `$cast` is a typecheck by
30−mold.
31−
32−### `:name`, `^=`, "kettis", `{$name p/@tas q/twig}
33−
34−Syntax: *2-fixed*.
35−
36−The product: the formula of `q`, with the span of `q` labeled by
37−symbol `p`.
38−
39−### Irregular forms
40−
41−### Backtick cast: `\`foo\`bar`
42−
43−Translation:
44−```
45−`foo`bar ^-(foo bar)
46−```
47−
48−### Infix name: `foo=bar`
49−
50−Translation:
51−```
52−foo=bar ^=(foo bar)
53−```
docs/programming/hoon/twig/cell.mddeleted−83
@@ -1,83 +0,0 @@
1−---
2−sort: 4
3−---
4−
5−# Cell construction (`:` runes)
6−
7−The cell twigs, `$cons` and friends, are simple and regular.
8−All `:` twigs expand to `$cons`.
9−
10−## Twigs
11−
12−```
13−|%
14−++ twig
15− {$scon p/twig q/twig}
16− {$conq p/twig q/twig r/twig s/twig}
17− {$cons p/twig q/twig}
18− {$cont p/twig q/twig r/twig}
19− {$conl p/(list twig)}
20− {$conp p/(list twig)}
21−--
22−```
23−
24−All construction stems expand to one natural stem, `$cons`, the
25−pair constructor, named for the Lisp special form.
26−
27−Synthetic stems change the last letter to indicate the bulb type:
28−`$cont` for triple, `$conq` for quad, `$conp` for tuple, `$conl`
29−for list. `$scon` is the reverse.
30−
31−## Regular forms
32−
33−The rune prefix is `:`. Suffixes: `-` for pair, `+` for triple,
34−`^` for quad, `*` for tuple, `~` for list, `_` for reverse.
35−
36−### `:cons`, `:-`, "colhep", `{$cons p/twig q/twig}`,
37−
38−*Construct a cell (2-tuple*).
39−
40−Syntax: *2-fixed*.
41−
42−The product: the cell of `p` and `q`, each compiled against
43−the subject.
44−
45−### `:cont`, `:+`, "collus", `{$cont p/twig q/twig r/twig}`,
46−
47−Syntax: *3-fixed*.
48−
49−Expands to: `:cons(p :cons(q r))`.
50−
51−### `:conq`, `:^`, "colket", `{$cont p/twig q/twig r/twig s/twig}`,
52−
53−Syntax: *4-fixed*.
54−
55−Expands to: `:cons(p :cont(q r s))`.
56−
57−### `:conp`, `:*`, "coltar", `{$conp p/(list twig)}`,
58−
59−Syntax: *running*.
60−
61−Expands by: `|-(?~(p ~ ?~(t.p i.p [%cons i.p $(p t.p)])))`.
62−
63−### `:conl`, `:~`, "colsig", `{$conl p/(list twig)}`, "construct list"
64−
65−Syntax: *running*.
66−
67−Expands by: `|-(?~(p [%rock %n ~] [%cons i.p $(p t.p)]))`.
68−
69−### `:scon`, `:_`, "colcab", `{$scon p/twig q/twig}`, "construct backward"
70−
71−Syntax: *running*.
72−
73−Expands to: `[%cons q p]`.
74−
75−## Irregular forms
76−
77−### Bracket tuple, `[p q r s]`
78−
79−Translation:
80−
81−```
82−[p q r s] :conp(p q r s)
83−```
docs/programming/hoon/twig/cen-call.mdnew file+16
@@ -0,0 +1,16 @@
1+---
2+sort: 6
3+next: true
4+---
5+
6+# Full make (`%` runes)
7+
8+We've already covered the irregular-only twigs `$wing` and
9+`$limb`. These are simple forms of the *invocation* family of
10+twigs, `%`, whose general form is `$make`, `%=`.
11+
12+## Twigs
13+
14+<list dataPreview="true" className="runes" linkToFragments="true"></list>
15+
16+<kids className="runes"></kids>
docs/programming/hoon/catalog/cen-call/cab-keep.md → docs/programming/hoon/twig/cen-call/cab-keep.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/dot-lace.md → docs/programming/hoon/twig/cen-call/dot-lace.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/hep-call.md → docs/programming/hoon/twig/cen-call/hep-call.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/ket-calq.md → docs/programming/hoon/twig/cen-call/ket-calq.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/lus-calt.md → docs/programming/hoon/twig/cen-call/lus-calt.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/sig-open.md → docs/programming/hoon/twig/cen-call/sig-open.mdrenamed

The content is the same.

docs/programming/hoon/catalog/cen-call/tis-make.md → docs/programming/hoon/twig/cen-call/tis-make.mdrenamed

The content is the same.

docs/programming/hoon/twig/col-cell.mdnew file+15
@@ -0,0 +1,15 @@
1+---
2+sort: 3
3+next: true
4+---
5+
6+# Cell construction (`:` runes)
7+
8+The cell twigs, `$cons` and friends, are simple and regular.
9+All `:` twigs expand to `$cons`.
10+
11+## Twigs
12+
13+<list dataPreview="true" className="runes" linkToFragments="true"></list>
14+
15+<kids className="runes"></kids>
docs/programming/hoon/catalog/col-cell/cab-scon.md → docs/programming/hoon/twig/col-cell/cab-scon.mdrenamed

The content is the same.

docs/programming/hoon/catalog/col-cell/hep-cons.md → docs/programming/hoon/twig/col-cell/hep-cons.mdrenamed

The content is the same.

docs/programming/hoon/catalog/col-cell/ket-conq.md → docs/programming/hoon/twig/col-cell/ket-conq.mdrenamed

The content is the same.

docs/programming/hoon/catalog/col-cell/lus-cont.md → docs/programming/hoon/twig/col-cell/lus-cont.mdrenamed

The content is the same.

docs/programming/hoon/catalog/col-cell/sig-conl.md → docs/programming/hoon/twig/col-cell/sig-conl.mdrenamed

The content is the same.

docs/programming/hoon/catalog/col-cell/tar-conp.md → docs/programming/hoon/twig/col-cell/tar-conp.mdrenamed

The content is the same.

docs/programming/hoon/twig/core.mddeleted−90
@@ -1,90 +0,0 @@
1−---
2−sort: 6
3−---
4−
5−# Cores (`|` runes)
6−
7−Core twigs are flow twigs. The compiler essentially pins a Nock
8−formula, or battery of formulas, to the subject.
9−
10−All `|` twigs are macros around `$core`. (See the `$core`
11−section in [`span`](../span) above.) `$core` uses the subject as
12−the payload of a battery, whose arms are compiled with the core
13−itself as the subject.
14−
15−## Regular forms
16−
17−The rune prefix is `|`. Suffixes: `%` for `:core`, `=` for
18−`:gate`, `-` for `:loop`, `.` for `:trap`, `_` for `:door`.
19−
20−### `:core`, `|%`, "barcen", `{$core p/(map term twig)}`
21−
22−Syntax: *battery*
23−
24−The product: a core with battery `p`. Payload is the subject.
25−
26−### `:gate`, `|=`, "bartis", `{$gate p/moss q/twig}
27−
28−Syntax: *2-fixed*.
29−
30−Expands to:
31−
32−```
33−:new p
34−:core
35−++ $
36− q
37−--
38−```
39−
40−A `$gate` produces a function from `p` to `q`. `p` is the
41−*sample*, or argument. The core has one formula, named `$` (the
42−empty name). The payload is of the form `{sample context}`,
43−where `context` is the subject of the gate.
44−
45−### `:loop`, `|-`, "barhep", `{$loop p/twig}`
46−
47−Syntax: *1-fixed*.
48−
49−Expands to:
50−
51−```
52− :rap $
53− :core
54− ++ $
55− p
56− --
57−```
58−
59−A `$loop` makes a core with one anonymous arm `p`, then takes
60−that arm.
61−
62−### `:trap`, `|.`, "bardot", `{$trap p/twig}`
63−
64−Syntax: *1-fixed*.
65−
66−Expands to:
67−
68−```
69− :core
70− ++ $ p
71− --
72−```
73−
74−A `$trap` is a deferred value.
75−
76−### `:door`, `|_`, "barcab", `{$door p/moss q/(map term twig)}`
77−
78−Syntax: *1-fixed*, then *battery*.
79−
80−Expands to:
81−
82−```
83− :new p
84− :core
85− q
86− ==
87−```
88−
89−A `gate` is a function; a `door` is the general case of a
90−function. Wut? We'll look at this again from the caller's side.
docs/programming/hoon/twig/dot-nock.mdnew file+14
@@ -0,0 +1,14 @@
1+---
2+sort: 10
3+next: true
4+---
5+
6+# Intrinsics (`.` runes)
7+
8+Anything Nock can do, Hoon can do also.
9+
10+## Twigs
11+
12+<list dataPreview="true" className="runes" linkToFragments="true"></list>
13+
14+<kids className="runes"></kids>
docs/programming/hoon/catalog/dot-nock/ket-wish.md → docs/programming/hoon/twig/dot-nock/ket-wish.mdrenamed

The content is the same.

docs/programming/hoon/catalog/dot-nock/lus-bump.md → docs/programming/hoon/twig/dot-nock/lus-bump.mdrenamed

The content is the same.

docs/programming/hoon/catalog/dot-nock/tar-nock.md → docs/programming/hoon/twig/dot-nock/tar-nock.mdrenamed

The content is the same.

docs/programming/hoon/catalog/dot-nock/tis-same.md → docs/programming/hoon/twig/dot-nock/tis-same.mdrenamed

The content is the same.

docs/programming/hoon/catalog/dot-nock/wut-deep.md → docs/programming/hoon/twig/dot-nock/wut-deep.mdrenamed

The content is the same.

docs/programming/hoon/twig/flow.mddeleted−143
@@ -1,143 +0,0 @@
1−---
2−sort: 5
3−---
4−
5−# Subject flow (`=` runes)
6−
7−Flow twigs change the subject. (Or more precisely, a flow twig
8−compiles at least one of its subtwigs with a different subject.)
9−All non-flow twigs (except cores) pass the subject down unchanged.
10−
11−## Overview
12−
13−The simplest way to change the subject is to compose two twigs,
14−`p` and `q`. Let `x` be `(mint subject p)`, with product span
15−`p.x` and nock formula `q.x`. Let `y` be `(mint p.x q)`. Then
16−their composition is `[p.y [7 q.x q.y]]`.
17−
18−This composition is the `$per` twig. A close relative is `$pin`,
19−which is `$per` over `[p .]`. The new subject is a cell of `p`
20−and the old subject. `$pin` is the simplest Hoon equivalent of
21−"declaring a variable" (introducing new data into the subject).
22−
23−Another way to change the subject is to mutate it. With the
24−`$set` twig, given a wing that resolves to a leg, we can write
25−instead of reading, *installing* a new value at that leg. Of
26−course, we are creating a copy, not modifying the original.
27−
28−## Structures
29−
30−### `taco`: name with optional filling
31−
32−A `taco` is either a symbol or a symbol-mold cell. The mold is a
33−typecheck and cast. For instance, when "initializing a variable"
34−with `:var`, we can cast the inferred type of the initial value
35−to match an explicit `taco` mold, or just state the symbol and
36−use the inferred type.
37−
38−The `taco` syntax is `foo` for the symbol foo, or `foo/bar` for
39−symbol `foo` and mold `bar`.
40−
41−## Definitions
42−
43−The rune prefix is `=`. Suffixes: `>` for `:per`, `<` for
44−`:rap`, `+` for `:pin`, `-` for `:nip`, `|` for `:new`, `/` for
45−`:var`, `;` for `:rev`, `.` for `:set`, and `^` for `:sip`.
46−
47−### `:per`, `=>`, "tisgar", `{$per p/twig q/twig}`, "compose"
48−
49−The product: `q`, compiled against the product of `p`.
50−
51−Intuitively: uses `p` as the subject of `q`.
52−
53−### `:rap`, `=<`, "tisgal", `{$rap p/twig q/twig}`, "reverse compose"
54−
55−Expands to: `:per(q p)`
56−
57−Intuitively: reverse of `:per`.
58−
59−### `:pin`, `=+`, "tislus", `{$pin p/twig q/twig}`, "work with"
60−
61−Expands to: `:per(:cons(p .) q)`
62−
63−Intuitively: uses `[p subject]` as the subject of `q`.
64−
65−### `:nip`, `=-`, "tishep", `{$nip p/twig q/twig}`, "work over"
66−
67−Expands to: `:pin(q p)`
68−
69−Intuitively: reverse of `:pin`.
70−
71−### `:var`, `=/`, "tisfas", `{$var p/taco q/twig r/twig}, "with variable"
72−
73−Expands to: `?@(p :pin(:name(p q) r) :pin(:cast(:(coat p) q) r)`
74−
75−Intuitively: uses `[p=q subject]` as the subject of `r`. If `p`
76−contains a mold, cast `q` to that mold.
77−
78−### `:rev`, `=;`, "tissem", `{$var p/taco q/twig r/twig}, "over variable"
79−
80−Expands to: `:var(p r q)`
81−
82−Intuitively: reverse of `:var`.
83−
84−### `:new`, `=|`, "tisbar", `{$new p/moss q/twig}`, "with blank"
85−
86−Expands to: `:pin(:per($ p) q)`
87−
88−Intuitively: pin the default value of `p`.
89−
90−### `:set`, `=.`, "tisdot", `{$set p/wing q/twig r/twig}`, "mutate"
91−
92−The product: `r`, compiled against a version of the subject
93−with wing `p` modified to the product of `q`.
94−
95−Intuitively: `r` with `p` set to `q`. Almost an assignment.
96−
97−### `:sip`, `=^`, "tisket", `{$sip p/taco q/wing r/twig s/twig}`, "advance"
98−
99−The product is `s`, compiled against a version of the subject
100−in which the head of `r` is bound to variable `p`, and the tail
101−of `r` is assigned into the wing `q`.
102−
103−Intuitively: `r` produces a cell; we pin the head and install the
104−tail.
105−
106−Whyuppose we have a state machine with a function that
107−produces a cell, whose head is a result and whose tail is a new
108−state. We want to use the head as a new variable, and stuff the
109−tail back into wherever we stored the old state. This may also
110−remind you of Haskell's State monad.
111−
112−## Irregular forms
113−
114−### Infix colon, p:q
115−
116−Not to be confused with the wing `p.q`. Translation:
117−```
118−p:q:r :rap(p :rap(q r))
119−```
120−
121−## Structures
122−
123−Using a mold syntax we haven't learned yet:
124−
125−```
126−|%
127−++ taco
128− ?@(term {term moss})
129−::
130−++ twig
131− {$per p/twig q/twig}
132− {$rap p/twig q/twig}
133−
134− {$pin p/twig q/twig}
135− {$nip p/twig q/twig}
136−
137− {$new p/moss q/twig}
138− {$var p/taco q/twig r/twig}
139− {$rev p/taco q/twig r/twig}
140− {$set p/wing q/twig r/twig}
141− {$sip p/taco q/wing r/twig s/twig}
142−--
143−```
docs/programming/hoon/twig/ket-cast.mdnew file+18
@@ -0,0 +1,18 @@
1+---
2+sort: 9
3+next: true
4+---
5+
6+# Type manipulation (`^` runes).
7+
8+`$cast`, `$like`, and `$name` let us adjust spans without
9+violating type constraints.
10+
11+The `nest` algorithm which tests span subtyping is conservative;
12+it never allows invalid nests, it sometimes rejects valid nests.
13+
14+## Twigs
15+
16+<list dataPreview="true" className="runes" linkToFragments="true"></list>
17+
18+<kids className="runes"></kids>
docs/programming/hoon/catalog/ket-cast/bar-iron.md → docs/programming/hoon/twig/ket-cast/bar-iron.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/hep-cast.md → docs/programming/hoon/twig/ket-cast/hep-cast.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/lus-like.md → docs/programming/hoon/twig/ket-cast/lus-like.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/pam-zinc.md → docs/programming/hoon/twig/ket-cast/pam-zinc.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/sig-burn.md → docs/programming/hoon/twig/ket-cast/sig-burn.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/tis-name.md → docs/programming/hoon/twig/ket-cast/tis-name.mdrenamed

The content is the same.

docs/programming/hoon/catalog/ket-cast/wut-lead.md → docs/programming/hoon/twig/ket-cast/wut-lead.mdrenamed

The content is the same.

docs/programming/hoon/twig/limb.md+2−1
@@ -1,5 +1,6 @@
1---
1---
2−sort: 3
2+sort: 2
3+next: true
3---
4---
4
5
5# Limbs and wings
6# Limbs and wings
docs/programming/hoon/twig/mold.mddeleted−136
@@ -1,136 +0,0 @@
1−---
2−sort: 8
3−---
4−
5−# Molds (`$` runes).
6−
7−A *mold* is a `gate` (function) that helps us build simple and
8−rigorous data structures. (In fact, since "mold" sounds nasty,
9−molds are often called "structures.")
10−
11−## Overview
12−
13−While Hoon can't check this property statically, a proper mold
14−is a *normalizer*: an idempotent function across all nouns. If
15−the sample of a gate has span `%noun`, and its body obeys the
16−constraint that for any x, `=((mold x) (mold (mold x)))`, it's a
17−rectifier and can be used as a mold.
18−
19−Twigs in the `$` family are macros designed for making molds.
20−But any Hoon twig may produce a mold. (This is why `moss` is a
21−synonym for `twig`).
22−
23−Many macros *bunt* a mold, producing `:per(mold $)`. This value,
24−simply the result of executing the gate on the default sample,
25−is a constant by definition and normally can be compiled as such.
26−The range of a mold (the span of its bunt) is called its *icon*.
27−
28−Molds have two uses: defining simple and rigorous structures, and
29−validating untrusted input data. Validation, though very
30−important, is a rare use case. Except for direct raw input,
31−it's generally a faux pas to rectify nouns at runtime -- or even
32−in userspace.
33−
34−As a structure definition, a mold has three common uses. One,
35−its bunt is a default value (such as the sample in a gate.) Two,
36−the product of some computation is cast to its icon, both
37−checking the type and regularizing it. Three, it's used as a
38−building block in other molds.
39−
40−## Regular forms
41−
42−The rune prefix is `$`. Suffixes:
43−
44−### `:bank`, `$:`, "buccol", `{$bank p/(list moss)}`
45−
46−Syntax: *running*.
47−
48−The product: a rectifier gate producing the tuple `p`.
49−
50−Where `a`, `b` and `c` produce molds, `:bank(a b c)` produces a
51−mold whose icon is the span `[$.a $.b $.c]`.
52−
53−### `:coat`, `$=`, "buctis", `{$coat p/@tas q/moss}`
54−
55−Syntax: *2-fixed*.
56−
57−The product: a rectifier gate producing mold `q` under label `p`.
58−
59−Where `q` produces a mold, `:coat(p q)` produces a mold whose
60−icon matches the span of `:name(p $.q)`.
61−
62−### `:pick`, `$?`, "bucwut", `{$pick p/(list moss)}`
63−
64−Syntax: *running*.
65−
66−The product: a rectifier gate producing the union of the molds in
67−`p`.
68−
69−Where `a`, `b`, and `c` produce molds, `:pick(a b c)` produces a
70−mold whose icon matches the span of `?:(& $.a ?:(& $.b $.c))`.
71−
72−The default mold is the first item in `p`. To avoid an infinite
73−loop, it has to be a termination case (such as a constant).
74−
75−### `:book`, `$%`, "buccen", `{$book p/(list moss)}`
76−
77−Syntax: *running*.
78−
79−The product: a rectifier gate producing the tagged union of the
80−molds in `p`, all of which must be of the form `:bank(stem
81−bulb)`, where `stem` is an atomic mold.
82−
83−`$book` has the same icon as `$pick`, but rectifies better.
84−
85−The default mold is the first item in `p`. To avoid an infinite
86−loop, it has to be a termination case (such as a constant).
87−
88−### `:shoe`, `$_`, "buccab", "{$shoe p/twig}"
89−
90−Syntax: *1-fixed*.
91−
92−Expands to: `:gate(* p)`.
93−
94−A `$shoe` is not useful for rectification; it ignores its input.
95−It is only useful for defaults and typechecks. Sometimes we have
96−no choice but to describe by example.
97−
98−### `:lamb`, `$-`, `"buchep"`, `{$lamb p/moss q/moss}`
99−
100−Syntax: *1-fixed*.
101−
102−Expands to: `:shoe(:gate(p $.q))`.
103−
104−`$lamb` is a lambda. We shoe a trivial function from `p` to `q`.
105−Like any `$shoe`, a `$lamb` is not useful for rectification (eg,
106−you can't use it to typecheck cores sent over the network).
107−
108−## Irregular forms
109−
110−### Primitives
111−
112−`*` means any noun; `@` with an aura means an atom, such as `@ud`
113−for unsigned decimal, or just `@` for a generic noun; `?` for
114−boolean; `^` for a cell (of `*`).
115−
116−### Constants
117−
118−For a mold producing a cold atom, replace the `%` of the constant
119−syntax with `$`. `%42` is the constant number `42`; `$42` is a
120−function that, passed 42 or any other argument, produces `%42`.
121−
122−Similarly, `%foo` is the number `7.303.014` or `0x6f.6f66`;
123−`$foo` is a function that produces `%foo`.
124−
125−`$~` produces `~`.
126−
127−### Miscellaneous
128−
129−Translation:
130−
131−```
132−{a b c} :bank(a b c)
133−a/b :coat(a b)
134−?(a b c) :pick(a b c)
135−_a :shoe(a)
136−```
docs/programming/hoon/twig/nock.mddeleted−36
@@ -1,36 +0,0 @@
1−---
2−sort: 11
3−---
4−
5−# Intrinsics (`.` runes)
6−
7−Anything Nock can do, Hoon can do.
8−
9−## Regular forms
10−
11−### `:bump`, `.+`, "dotlus", `{$bump p/twig}`
12−
13−Syntax: *1-fixed*
14−
15−The product: the product of `p`, which must be an atom, plus 1.
16−
17−### `:same`, `.=`, "dottis", `{$same p/twig q/twig}`
18−
19−Syntax: *2-fixed*.
20−
21−The product: yes iff `p` and `q` produce the same value. The span
22−of `p` must nest within the span of `q`, or vice versa.
23−
24−### `:nock`, `.*`, "dottar", `{$nock p/twig q/twig}`
25−
26−The product: Nock of the formula produced by `q`, with the
27−subject produced by `p`. Typeless.
28−
29−### `:wish`, `.^`, "dotket", `{$wish p/moss q/twig}`
30−
31−The product: the noun `q` dereferenced in the Urbit global
32−namespace. The product must nest within the icon of `p`.
33−
34−Only available in user-level code. Not blocking except in
35−dojo-level code (blocks for a generator, fails if it would block
36−for an app).
docs/programming/hoon/twig/sem-make.mdnew file+14
@@ -0,0 +1,14 @@
1+---
2+sort: 11
3+next: true
4+---
5+
6+# Macros (`;` runes)
7+
8+Miscellaneous useful macros.
9+
10+## Twigs
11+
12+<list dataPreview="true" className="runes" linkToFragments="true"></list>
13+
14+<kids className="runes"></kids>
docs/programming/hoon/catalog/sem-make/col-wad.md → docs/programming/hoon/twig/sem-make/col-wad.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sem-make/fas-nub.md → docs/programming/hoon/twig/sem-make/fas-nub.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sem-make/sem-fry.md → docs/programming/hoon/twig/sem-make/sem-fry.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sem-make/sig-dip.md → docs/programming/hoon/twig/sem-make/sig-dip.mdrenamed

The content is the same.

docs/programming/hoon/twig/sig-hint.mdnew file+15
@@ -0,0 +1,15 @@
1+---
2+sort: 12
3+next: true
4+---
5+
6+# Hints (`~` runes)
7+
8+Twigs that use Nock `10` to pass non-semantic info to the
9+interpreter.
10+
11+## Twigs
12+
13+<list dataPreview="true" className="runes" linkToFragments="true"></list>
14+
15+<kids className="runes"></kids>
docs/programming/hoon/catalog/sig-hint/bar-show.md → docs/programming/hoon/twig/sig-hint/bar-show.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/buc-poll.md → docs/programming/hoon/twig/sig-hint/buc-poll.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/cab-lurk.md → docs/programming/hoon/twig/sig-hint/cab-lurk.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/cen-fast.md → docs/programming/hoon/twig/sig-hint/cen-fast.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/fas-funk.md → docs/programming/hoon/twig/sig-hint/fas-funk.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/gal-thin.md → docs/programming/hoon/twig/sig-hint/gal-thin.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/gar-hint.md → docs/programming/hoon/twig/sig-hint/gar-hint.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/lus-memo.md → docs/programming/hoon/twig/sig-hint/lus-memo.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/pam-dump.md → docs/programming/hoon/twig/sig-hint/pam-dump.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/tis-ddup.md → docs/programming/hoon/twig/sig-hint/tis-ddup.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/wut-warn.md → docs/programming/hoon/twig/sig-hint/wut-warn.mdrenamed

The content is the same.

docs/programming/hoon/catalog/sig-hint/zap-peep.md → docs/programming/hoon/twig/sig-hint/zap-peep.mdrenamed

The content is the same.

docs/programming/hoon/twig/test.mddeleted−143
@@ -1,143 +0,0 @@
1−---
2−sort: 9
3−---
4−
5−# Tests (`?` runes)
6−
7−Hoon has the usual branches and logical tests. For pattern
8−matching, it also has a `$fits` twig that tests whether a value
9−matches the icon of a mold. And it has branch inference,
10−learning from `$fits` tests in the condition of `:if` twigs.
11−
12−## Overview
13−
14−All `?` runes expand to `$if` (`?:`) and/or `$fits` (`?=`).
15−
16−If the condition of an `$if` is a `$fits`, *and* the `$fits` is
17−testing a leg of the subject, the compile specializes the subject
18−span for the branches of the `$if`. Branch inference also works
19−for twigs which expand to `$if`.
20−
21−The test does not have to be a single `$fits`; the compiler can
22−analyze arbitrary boolean logic (`$and`, `$or`, `$not`) with full
23−short-circuiting. Equality tests (`=`) are *not* analyzed.
24−
25−If the compiler detects that the branch is degenerate (only one
26−side is taken), it fails with an error.
27−
28−## Regular forms
29−
30−The rune prefix is `?`. Suffixes: `=` for `:fits`, `:` for
31−`:if`, `.` for `:lest`, `-` for `:case`, `+` for `:deft`, `|` for
32−`:or`, `&` for `:and`, `!` for `:not`, `>` for `$sure`, `<` for
33−`$deny`, `^` for `:ifcl`, `@` for `:ifat`, `~` for `:ifno`.
34−
35−### `:fits`, `?=`, "wuttis", `{$fits p/moss q/twig}`
36−
37−Syntax: *2-fixed*.
38−
39−The product: `&` if the product of `q` is in the icon of `p`,
40−`|` otherwise.
41−
42−The icon of `p` must be finite / nonrecursive. In general,
43−always match one layer of a data structure at a time.
44−
45−### `:if`, `?:`, "wutcol", `{$if p/twig q/twig r/twig}`
46−
47−Syntax: *3-fixed*.
48−
49−The product: `q` if `p` has the value `&` (0), `r` for `|` (1).
50−`p` must be statically boolean.
51−
52−### `:lest`, `?.`, "wutdot", `{$lest p/twig q/twig r/twig}`
53−
54−Syntax: *3-fixed*.
55−
56−Expands to: `:if(p r q)`.
57−
58−### `:case`, `?-`, "wuthep", `{$case p/twig q/(list (pair moss twig))}`
59−
60−Syntax: *1-fixed*, then *jogging*.
61−
62−Expands by:
63−
64−```
65−|-(?~(q [%lost p] [%if [%fits p.i.q p] q.i.q $(q t.q)]))
66−```
67−
68−A pattern-matching switch. Fails to compile if the pattern is
69−incomplete or irrelevant.
70−
71−### `:deft`, `?+`, "wutlus", `{$case p/twig q/twig r/(list (pair moss twig))}`
72−
73−Syntax: *1-fixed*, then *jogging*.
74−
75−Expands by: `[%case p (weld r [[%base %noun] q])]`
76−
77−A pattern-matching switch, with default.
78−
79−### `:or`, `?|`, "wutbar", `{$or p/(list twig)}`
80−
81−Syntax: *running*.
82−
83−Expands by: `|-(?~(p [%rock %f |] [%if i.p [%rock %f &]] $(p t.p)))`
84−
85−Logical or (`&` (`0`) is yes, `|` (`1`) is no).
86−
87−### `:and`, `?&`, "wutpam", `{$and p/(list twig)}`
88−
89−Syntax: *running*.
90−
91−Expands by: `|-(?~(p [%rock %f &] [%if i.p $(p t.p) [%rock %f |]]))`
92−
93−Logical and (`&` (`0`) is yes, `|` (`1`) is no).
94−
95−### `:not`, `?!`, "wutzap", `{$not p/twig}`
96−
97−Syntax: *1-fixed*.
98−
99−Expands to: `:if(p %| %&)`.
100−
101−Logical not (`&` (`0`) is yes, `|` (`1`) is no).
102−
103−### `:sure`, `?>`, "wutgar", `{$sure p/twig q/twig}`
104−
105−Expands to: `:if(p q !!)`.
106−
107−An assertion.
108−
109−### `:deny`, `?<`, "wutgal", `{$deny p/twig q/twig}`
110−
111−Expands to: `:if(p !! q)`.
112−
113−A negative assertion.
114−
115−### `:ifno`, `?~`, "wutsig", `{$ifno p/twig q/twig r/twig}`
116−
117−Expands to: `:if(:fits($~ p) q r)`.
118−
119−Branches on whether `p` is null.
120−
121−### `:ifat`, `?@`, "wutpat", `{$ifat p/twig q/twig r/twig}`
122−
123−Expands to: `:if(:fits(@ p) q r)`.
124−
125−Branches on whether `p` is atomic.
126−
127−### `:ifcl`, `?^`, "wutket", `{$ifat p/twig q/twig r/twig}`
128−
129−Expands to: `:if(:fits(^ p) q r)`.
130−
131−Branches on whether `p` is cellular.
132−
133−## Irregular forms
134−
135−### Light logic
136−
137−Translations:
138−
139−```
140−&(a b c) ?&(a b c)
141−|(a b c) ?|(a b c)
142−!a ?!(a)
143−```
docs/programming/hoon/twig/tis-flow.mdnew file+33
@@ -0,0 +1,33 @@
1+---
2+sort: 4
3+next: true
4+---
5+
6+# Subject flow (`=` runes)
7+
8+Flow twigs change the subject. (Or more precisely, a flow twig
9+compiles at least one of its subtwigs with a different subject.)
10+All non-flow twigs (except cores) pass the subject down unchanged.
11+
12+## Overview
13+
14+The simplest way to change the subject is to compose two twigs,
15+`p` and `q`. Let `x` be `(mint subject p)`, with product span
16+`p.x` and nock formula `q.x`. Let `y` be `(mint p.x q)`. Then
17+their composition is `[p.y [7 q.x q.y]]`.
18+
19+This composition is the `$per` twig. A close relative is `$pin`,
20+which is `$per` over `[p .]`. The new subject is a cell of `p`
21+and the old subject. `$pin` is the simplest Hoon equivalent of
22+"declaring a variable" (introducing new data into the subject).
23+
24+Another way to change the subject is to mutate it. With the
25+`$set` twig, given a wing that resolves to a leg, we can write
26+instead of reading, *installing* a new value at that leg. Of
27+course, we are creating a copy, not modifying the original.
28+
29+## Twigs
30+
31+<list dataPreview="true" className="runes" linkToFragments="true"></list>
32+
33+<kids className="runes"></kids>
docs/programming/hoon/catalog/tis-flow/bar-new.md → docs/programming/hoon/twig/tis-flow/bar-new.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/col-fix.md → docs/programming/hoon/twig/tis-flow/col-fix.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/dot-set.md → docs/programming/hoon/twig/tis-flow/dot-set.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/fas-var.md → docs/programming/hoon/twig/tis-flow/fas-var.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/gal-rap.md → docs/programming/hoon/twig/tis-flow/gal-rap.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/gar-per.md → docs/programming/hoon/twig/tis-flow/gar-per.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/hep-nip.md → docs/programming/hoon/twig/tis-flow/hep-nip.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/ket-sip.md → docs/programming/hoon/twig/tis-flow/ket-sip.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/lus-pin.md → docs/programming/hoon/twig/tis-flow/lus-pin.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/sem-rev.md → docs/programming/hoon/twig/tis-flow/sem-rev.mdrenamed

The content is the same.

docs/programming/hoon/catalog/tis-flow/tar-aka.md → docs/programming/hoon/twig/tis-flow/tar-aka.mdrenamed

The content is the same.

docs/programming/hoon/twig/wut-test.mdnew file+33
@@ -0,0 +1,33 @@
1+---
2+sort: 8
3+next: true
4+---
5+
6+# Tests (`?` runes)
7+
8+Hoon has the usual branches and logical tests. For pattern
9+matching, it also has a `$fits` twig that tests whether a value
10+matches the icon of a mold. And it has branch inference,
11+learning from `$fits` tests in the condition of `:if` twigs.
12+
13+## Overview
14+
15+All `?` runes expand to `$if` (`?:`) and/or `$fits` (`?=`).
16+
17+If the condition of an `$if` is a `$fits`, *and* the `$fits` is
18+testing a leg of the subject, the compile specializes the subject
19+span for the branches of the `$if`. Branch inference also works
20+for twigs which expand to `$if`.
21+
22+The test does not have to be a single `$fits`; the compiler can
23+analyze arbitrary boolean logic (`$and`, `$or`, `$not`) with full
24+short-circuiting. Equality tests (`=`) are *not* analyzed.
25+
26+If the compiler detects that the branch is degenerate (only one
27+side is taken), it fails with an error.
28+
29+## Twigs
30+
31+<list dataPreview="true" className="runes" linkToFragments="true"></list>
32+
33+<kids className="runes"></kids>
docs/programming/hoon/catalog/wut-test/bar-or.md → docs/programming/hoon/twig/wut-test/bar-or.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/col-if.md → docs/programming/hoon/twig/wut-test/col-if.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/dot-lest.md → docs/programming/hoon/twig/wut-test/dot-lest.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/gal-deny.md → docs/programming/hoon/twig/wut-test/gal-deny.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/gar-sure.md → docs/programming/hoon/twig/wut-test/gar-sure.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/hep-case.md → docs/programming/hoon/twig/wut-test/hep-case.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/ket-ifcl.md → docs/programming/hoon/twig/wut-test/ket-ifcl.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/lus-deft.md → docs/programming/hoon/twig/wut-test/lus-deft.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/pam-and.md → docs/programming/hoon/twig/wut-test/pam-and.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/pat-ifat.md → docs/programming/hoon/twig/wut-test/pat-ifat.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/sig-ifno.md → docs/programming/hoon/twig/wut-test/sig-ifno.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/tis-fits.md → docs/programming/hoon/twig/wut-test/tis-fits.mdrenamed

The content is the same.

docs/programming/hoon/catalog/wut-test/zap-not.md → docs/programming/hoon/twig/wut-test/zap-not.mdrenamed

The content is the same.

docs/programming/hoon/catalog/dot-nock.md → docs/programming/hoon/twig/zap-wild.mdrenamed+4−3
@@ -1,10 +1,11 @@
1---
1---
2−sort: 5
2+sort: 13
3+next: true
3---
4---
4
5
5−# `. dot` (nock)
6+# Special tools (`!` runes).
6
7
7−##### Run some nock.
8+## Twigs
8
9
9<list dataPreview="true" className="runes" linkToFragments="true"></list>
10<list dataPreview="true" className="runes" linkToFragments="true"></list>
10
11
docs/programming/hoon/catalog/zap-wild/gar-wrap.md → docs/programming/hoon/twig/zap-wild/gar-wrap.mdrenamed

The content is the same.

docs/programming/hoon/catalog/zap-wild/tis-code.md → docs/programming/hoon/twig/zap-wild/tis-code.mdrenamed

The content is the same.

docs/programming/hoon/catalog/zap-wild/wut-need.md → docs/programming/hoon/twig/zap-wild/wut-need.mdrenamed

The content is the same.

docs/programming/hoon/catalog/zap-wild/zap-fail.md → docs/programming/hoon/twig/zap-wild/zap-fail.mdrenamed

The content is the same.