on master help sign in
Proper commit of hoon reorg.
commit30fa28a0356fb4be57853de7080cdeb835c70e1e authorC. Guy Yarvin <cgyarvin@gmail.com> dateFri 22 Apr 2016, 10:39 (11 years ago) parent38ec1a6
147 files changed+887−2582
docs/programming/hoon/advanced.md+197 docs/programming/hoon/span.md → docs/programming/hoon/basic.md+23−31 docs/programming/hoon/catalog.md+14−14 docs/programming/hoon/catalog/bar-core.md−29 docs/programming/hoon/catalog/buc-mold.md−26 docs/programming/hoon/catalog/cen-call.md−27 docs/programming/hoon/catalog/col-cell.md−24 docs/programming/hoon/catalog/ket-cast.md−24 docs/programming/hoon/catalog/misc.md−50 docs/programming/hoon/catalog/misc/base.md docs/programming/hoon/catalog/misc/buc-bunt.md−5 docs/programming/hoon/catalog/misc/bust.md docs/programming/hoon/catalog/misc/dbug.md docs/programming/hoon/catalog/misc/hand.md docs/programming/hoon/catalog/misc/knit.md docs/programming/hoon/catalog/misc/leaf.md docs/programming/hoon/catalog/misc/limb.md docs/programming/hoon/catalog/misc/lost.md docs/programming/hoon/catalog/misc/rock.md docs/programming/hoon/catalog/misc/sand.md docs/programming/hoon/catalog/misc/tell.md docs/programming/hoon/catalog/misc/tune.md docs/programming/hoon/catalog/misc/wing.md docs/programming/hoon/catalog/misc/yell.md docs/programming/hoon/catalog/sem-make.md−22 docs/programming/hoon/catalog/sig-hint.md−36 docs/programming/hoon/catalog/tis-flow.md−31 docs/programming/hoon/catalog/wut-test.md−31 docs/programming/hoon/catalog/zap-wild.md−23 docs/programming/hoon/cheat-sheets.md−9 docs/programming/hoon/cheat-sheets/hoon.md−532 docs/programming/hoon/cheat-sheets/odors.md−686 docs/programming/hoon/cheat-sheets/pronunciation.md−68 docs/programming/hoon/concepts.md+19−5 docs/programming/hoon/demo.md+2−2 docs/programming/hoon/examples.md+2−1 docs/programming/hoon/library.md+3−4 docs/programming/hoon/mint.md−27 docs/programming/hoon/noun.md−37 docs/programming/hoon/philosophy.md+15−19 docs/programming/hoon/syntax.md+367 docs/programming/hoon/troubleshooting.md+2−1 docs/programming/hoon/twig.md+12−8 docs/programming/hoon/twig/atom.md+2−1 docs/programming/hoon/twig/bar-core.md+20 docs/programming/hoon/catalog/bar-core/cab-door.md → docs/programming/hoon/twig/bar-core/cab-door.md docs/programming/hoon/catalog/bar-core/cen-core.md → docs/programming/hoon/twig/bar-core/cen-core.md docs/programming/hoon/catalog/bar-core/dot-trap.md → docs/programming/hoon/twig/bar-core/dot-trap.md docs/programming/hoon/catalog/bar-core/hep-loop.md → docs/programming/hoon/twig/bar-core/hep-loop.md docs/programming/hoon/catalog/bar-core/tar-gill.md → docs/programming/hoon/twig/bar-core/tar-gill.md docs/programming/hoon/catalog/bar-core/tis-gate.md → docs/programming/hoon/twig/bar-core/tis-gate.md docs/programming/hoon/twig/buc-mold.md+45 docs/programming/hoon/catalog/buc-mold/cab-shoe.md → docs/programming/hoon/twig/buc-mold/cab-shoe.md docs/programming/hoon/catalog/buc-mold/cen-book.md → docs/programming/hoon/twig/buc-mold/cen-book.md docs/programming/hoon/catalog/buc-mold/col-bank.md → docs/programming/hoon/twig/buc-mold/col-bank.md docs/programming/hoon/catalog/buc-mold/hep-lamb.md → docs/programming/hoon/twig/buc-mold/hep-lamb.md docs/programming/hoon/catalog/buc-mold/ket-bush.md → docs/programming/hoon/twig/buc-mold/ket-bush.md docs/programming/hoon/catalog/buc-mold/pat-claw.md → docs/programming/hoon/twig/buc-mold/pat-claw.md docs/programming/hoon/catalog/buc-mold/tis-coat.md → docs/programming/hoon/twig/buc-mold/tis-coat.md docs/programming/hoon/catalog/buc-mold/wut-pick.md → docs/programming/hoon/twig/buc-mold/wut-pick.md docs/programming/hoon/twig/call.md−121 docs/programming/hoon/twig/cast.md−53 docs/programming/hoon/twig/cell.md−83 docs/programming/hoon/twig/cen-call.md+16 docs/programming/hoon/catalog/cen-call/cab-keep.md → docs/programming/hoon/twig/cen-call/cab-keep.md docs/programming/hoon/catalog/cen-call/dot-lace.md → docs/programming/hoon/twig/cen-call/dot-lace.md docs/programming/hoon/catalog/cen-call/hep-call.md → docs/programming/hoon/twig/cen-call/hep-call.md docs/programming/hoon/catalog/cen-call/ket-calq.md → docs/programming/hoon/twig/cen-call/ket-calq.md docs/programming/hoon/catalog/cen-call/lus-calt.md → docs/programming/hoon/twig/cen-call/lus-calt.md docs/programming/hoon/catalog/cen-call/sig-open.md → docs/programming/hoon/twig/cen-call/sig-open.md docs/programming/hoon/catalog/cen-call/tis-make.md → docs/programming/hoon/twig/cen-call/tis-make.md docs/programming/hoon/twig/col-cell.md+15 docs/programming/hoon/catalog/col-cell/cab-scon.md → docs/programming/hoon/twig/col-cell/cab-scon.md docs/programming/hoon/catalog/col-cell/hep-cons.md → docs/programming/hoon/twig/col-cell/hep-cons.md docs/programming/hoon/catalog/col-cell/ket-conq.md → docs/programming/hoon/twig/col-cell/ket-conq.md docs/programming/hoon/catalog/col-cell/lus-cont.md → docs/programming/hoon/twig/col-cell/lus-cont.md docs/programming/hoon/catalog/col-cell/sig-conl.md → docs/programming/hoon/twig/col-cell/sig-conl.md docs/programming/hoon/catalog/col-cell/tar-conp.md → docs/programming/hoon/twig/col-cell/tar-conp.md docs/programming/hoon/twig/core.md−90 docs/programming/hoon/twig/dot-nock.md+14 docs/programming/hoon/catalog/dot-nock/ket-wish.md → docs/programming/hoon/twig/dot-nock/ket-wish.md docs/programming/hoon/catalog/dot-nock/lus-bump.md → docs/programming/hoon/twig/dot-nock/lus-bump.md docs/programming/hoon/catalog/dot-nock/tar-nock.md → docs/programming/hoon/twig/dot-nock/tar-nock.md docs/programming/hoon/catalog/dot-nock/tis-same.md → docs/programming/hoon/twig/dot-nock/tis-same.md docs/programming/hoon/catalog/dot-nock/wut-deep.md → docs/programming/hoon/twig/dot-nock/wut-deep.md docs/programming/hoon/twig/flow.md−143 docs/programming/hoon/twig/ket-cast.md+18 docs/programming/hoon/catalog/ket-cast/bar-iron.md → docs/programming/hoon/twig/ket-cast/bar-iron.md docs/programming/hoon/catalog/ket-cast/hep-cast.md → docs/programming/hoon/twig/ket-cast/hep-cast.md docs/programming/hoon/catalog/ket-cast/lus-like.md → docs/programming/hoon/twig/ket-cast/lus-like.md docs/programming/hoon/catalog/ket-cast/pam-zinc.md → docs/programming/hoon/twig/ket-cast/pam-zinc.md docs/programming/hoon/catalog/ket-cast/sig-burn.md → docs/programming/hoon/twig/ket-cast/sig-burn.md docs/programming/hoon/catalog/ket-cast/tis-name.md → docs/programming/hoon/twig/ket-cast/tis-name.md docs/programming/hoon/catalog/ket-cast/wut-lead.md → docs/programming/hoon/twig/ket-cast/wut-lead.md docs/programming/hoon/twig/limb.md+2−1 docs/programming/hoon/twig/mold.md−136 docs/programming/hoon/twig/nock.md−36 docs/programming/hoon/twig/sem-make.md+14 docs/programming/hoon/catalog/sem-make/col-wad.md → docs/programming/hoon/twig/sem-make/col-wad.md docs/programming/hoon/catalog/sem-make/fas-nub.md → docs/programming/hoon/twig/sem-make/fas-nub.md docs/programming/hoon/catalog/sem-make/sem-fry.md → docs/programming/hoon/twig/sem-make/sem-fry.md docs/programming/hoon/catalog/sem-make/sig-dip.md → docs/programming/hoon/twig/sem-make/sig-dip.md docs/programming/hoon/twig/sig-hint.md+15 docs/programming/hoon/catalog/sig-hint/bar-show.md → docs/programming/hoon/twig/sig-hint/bar-show.md docs/programming/hoon/catalog/sig-hint/buc-poll.md → docs/programming/hoon/twig/sig-hint/buc-poll.md docs/programming/hoon/catalog/sig-hint/cab-lurk.md → docs/programming/hoon/twig/sig-hint/cab-lurk.md docs/programming/hoon/catalog/sig-hint/cen-fast.md → docs/programming/hoon/twig/sig-hint/cen-fast.md docs/programming/hoon/catalog/sig-hint/fas-funk.md → docs/programming/hoon/twig/sig-hint/fas-funk.md docs/programming/hoon/catalog/sig-hint/gal-thin.md → docs/programming/hoon/twig/sig-hint/gal-thin.md docs/programming/hoon/catalog/sig-hint/gar-hint.md → docs/programming/hoon/twig/sig-hint/gar-hint.md docs/programming/hoon/catalog/sig-hint/lus-memo.md → docs/programming/hoon/twig/sig-hint/lus-memo.md docs/programming/hoon/catalog/sig-hint/pam-dump.md → docs/programming/hoon/twig/sig-hint/pam-dump.md docs/programming/hoon/catalog/sig-hint/tis-ddup.md → docs/programming/hoon/twig/sig-hint/tis-ddup.md docs/programming/hoon/catalog/sig-hint/wut-warn.md → docs/programming/hoon/twig/sig-hint/wut-warn.md docs/programming/hoon/catalog/sig-hint/zap-peep.md → docs/programming/hoon/twig/sig-hint/zap-peep.md docs/programming/hoon/twig/test.md−143 docs/programming/hoon/twig/tis-flow.md+33 docs/programming/hoon/catalog/tis-flow/bar-new.md → docs/programming/hoon/twig/tis-flow/bar-new.md docs/programming/hoon/catalog/tis-flow/col-fix.md → docs/programming/hoon/twig/tis-flow/col-fix.md docs/programming/hoon/catalog/tis-flow/dot-set.md → docs/programming/hoon/twig/tis-flow/dot-set.md docs/programming/hoon/catalog/tis-flow/fas-var.md → docs/programming/hoon/twig/tis-flow/fas-var.md docs/programming/hoon/catalog/tis-flow/gal-rap.md → docs/programming/hoon/twig/tis-flow/gal-rap.md docs/programming/hoon/catalog/tis-flow/gar-per.md → docs/programming/hoon/twig/tis-flow/gar-per.md docs/programming/hoon/catalog/tis-flow/hep-nip.md → docs/programming/hoon/twig/tis-flow/hep-nip.md docs/programming/hoon/catalog/tis-flow/ket-sip.md → docs/programming/hoon/twig/tis-flow/ket-sip.md docs/programming/hoon/catalog/tis-flow/lus-pin.md → docs/programming/hoon/twig/tis-flow/lus-pin.md docs/programming/hoon/catalog/tis-flow/sem-rev.md → docs/programming/hoon/twig/tis-flow/sem-rev.md docs/programming/hoon/catalog/tis-flow/tar-aka.md → docs/programming/hoon/twig/tis-flow/tar-aka.md docs/programming/hoon/twig/wut-test.md+33 docs/programming/hoon/catalog/wut-test/bar-or.md → docs/programming/hoon/twig/wut-test/bar-or.md docs/programming/hoon/catalog/wut-test/col-if.md → docs/programming/hoon/twig/wut-test/col-if.md docs/programming/hoon/catalog/wut-test/dot-lest.md → docs/programming/hoon/twig/wut-test/dot-lest.md docs/programming/hoon/catalog/wut-test/gal-deny.md → docs/programming/hoon/twig/wut-test/gal-deny.md docs/programming/hoon/catalog/wut-test/gar-sure.md → docs/programming/hoon/twig/wut-test/gar-sure.md docs/programming/hoon/catalog/wut-test/hep-case.md → docs/programming/hoon/twig/wut-test/hep-case.md docs/programming/hoon/catalog/wut-test/ket-ifcl.md → docs/programming/hoon/twig/wut-test/ket-ifcl.md docs/programming/hoon/catalog/wut-test/lus-deft.md → docs/programming/hoon/twig/wut-test/lus-deft.md docs/programming/hoon/catalog/wut-test/pam-and.md → docs/programming/hoon/twig/wut-test/pam-and.md docs/programming/hoon/catalog/wut-test/pat-ifat.md → docs/programming/hoon/twig/wut-test/pat-ifat.md docs/programming/hoon/catalog/wut-test/sig-ifno.md → docs/programming/hoon/twig/wut-test/sig-ifno.md docs/programming/hoon/catalog/wut-test/tis-fits.md → docs/programming/hoon/twig/wut-test/tis-fits.md docs/programming/hoon/catalog/wut-test/zap-not.md → docs/programming/hoon/twig/wut-test/zap-not.md docs/programming/hoon/catalog/dot-nock.md → docs/programming/hoon/twig/zap-wild.md+4−3 docs/programming/hoon/catalog/zap-wild/gar-wrap.md → docs/programming/hoon/twig/zap-wild/gar-wrap.md docs/programming/hoon/catalog/zap-wild/tis-code.md → docs/programming/hoon/twig/zap-wild/tis-code.md docs/programming/hoon/catalog/zap-wild/wut-need.md → docs/programming/hoon/twig/zap-wild/wut-need.md docs/programming/hoon/catalog/zap-wild/zap-fail.md → docs/programming/hoon/twig/zap-wild/zap-fail.md
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 @@
11---
2−sort: 6
2+sort: 5
33next: true
4−title: Type: span
4+title: Basic types
55---
66
7−# Type: `span`
7+# Basic types
88
99A `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`.
1012
11−## Span, mold, type: what's in a type system?
13+## Span and mold
1214
1315There is no Hoon syntax for a span. The programmer never defines
1416a 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
2628function, or *mold*.
2729
2830A mold is an idempotent function (`gate`), accepting any noun.
29−(An idempotent function is one such that f(f(x)) equals f(x) if
30−f(x) does not crash.) The product range of the function is the
31+(An idempotent function is one such that *f(f(x))* equals *f(x)*
32+if *f(x)* terminates.) The product range of the function is the
3133span, or *icon*, of the mold.
3234
3335Usually 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
3537actually validating untrusted foreign data. As a beginner,
3638hopefully you aren't!
3739
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)
5541
5642Usually in Hoon we define the semantics of a primitive by the
5743state the span of all nouns that implement that primitive. We
5844state this span as the icon of a mold. That mold is produced by
5945a kernel arm `span`:
6046
47+This is a slightly simplified version of `span`. We'll undo and
48+explain the simplifications below.
49+
6150```
6251++ term @tas
6352++ span
@@ -65,7 +54,7 @@ a kernel arm `span`:
6554 $void
6655 == $% {$atom p/term q/(unit atom)}
6756 {$cell p/span q/span}
68− {$core p/span q/(map term span)}
57+ {$core p/span q/(map term twig)}
6958 {$face p/term q/span}
7059 {$fork p/(set span)}
7160 {$hold p/span q/twig}
@@ -78,26 +67,29 @@ pseudocode. If a span is an atom, it's either the atomic string
7867`atom`, `cell`, `core`, etc. We'll go through each of these
7968cases below.
8069
81−## `$noun` and `$void`
70+### `$noun` and `$void`
8271
8372`$noun` is the set of all nouns. `$void` is the set of no nouns.
8473
85−## `{$cell p/span q/span}`
74+### `{$cell p/span q/span}`
8675
8776`{$cell p/span q/span}` is the set of all cells with head `p` and
8877tail `q`.
8978
90−## `{$fork p/(set span)}
79+### `{$fork p/(set span)}
9180
9281`{$fork p/(set span)}` is the union of all spans in the set `p`.
9382
94−## `{$hold p/span q/twig}`
83+### `{$hold p/span q/twig}`
9584
9685A `$hold` span, with span `p` and twig `q`, is a lazy reference
9786to the span of `(mint p q)`. In English it means: "the type of
9887the product when we compile `q` against subject `p`.
9988
100−## `{$face p/term q/span}
89+This is "manual laziness." Hoon is a strict language, so we have
90+to express
91+
92+### `{$face p/term q/span}
10193
10294A `{$face p/term q/span}` wraps the label `p` around the span
10395`q`. `p` is a `term` or `@tas`, an atomic ASCII string which
@@ -107,7 +99,7 @@ first character must be lowercase.
10799See the [twig chapter](twig) for how labels are resolved. It's
108100nontrivial.
109101
110−## `{%atom p/term q/(unit atom))}
102+### `{%atom p/term q/(unit atom))}
111103
112104An `$atom` is an atom, with two twists. `q` is a `unit`, Hoon's
113105equivalent of a nullable pointer or a Haskell `Maybe`. If `q`
@@ -131,7 +123,7 @@ statically, by casting through the empty aura `@`. Hoon is not
131123dependently typed and can't statically enforce data constraints
132124(for example, it can't enforce that a `@tas` is really a symbol).
133125
134−## `{$core p/span q/(map term span)}
126+### `{$core p/span q/(map term span)}
135127
136128A `$core` is a code-data cell. The data (or *payload*) is the
137129tail; the code (or *battery*) is the head. `p`, a span, is the
docs/programming/hoon/catalog.md+14−14
@@ -1,76 +1,76 @@
11---
22sort: 10
3−title: Stems catalog
3+title: Twig reference
44---
55
6−# Stems
6+# Twig reference
77
8−#### A catalog of all Hoon stems:
8+#### A catalog of all twig stems:
99
1010<div class="book">
1111
1212## `$ buc` (mold)
1313
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>
1515
1616---
1717
1818## `| bar` (core)
1919
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>
2121
2222---
2323
2424## `: col` (cell)
2525
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>
2727
2828---
2929
3030## `% cen` (call)
3131
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>
3333
3434---
3535
3636## `. dot` (nock)
3737
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>
3939
4040---
4141
4242## `^ ket` (cast)
4343
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>
4545
4646---
4747
4848## `~ sig` (hint)
4949
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>
5151
5252---
5353
5454## `; sem` (make)
5555
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>
5757
5858---
5959
6060## `= tis` (flow)
6161
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>
6363
6464---
6565
6666## `? wut` (test)
6767
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>
6969
7070---
7171
7272## `! zap` (wild)
7373
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>
7575
7676</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?
1616
1717## Motivation
1818
19−Hoon has no close relatives, and the normal jargon of programming
19+Hoon has no close relatives. The normal jargon of programming
2020maps poorly onto its semantics. For example, although Hoon is a
2121typed language, the term "type" is not formally defined in Hoon.
2222"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
6464
6565### `nock` (interpreter)
6666
67−Hoon compiles itself to the [Nock](nock) VM. Nock is a
67+Hoon compiles itself to the [Nock](../nock) VM. Nock is a
6868Turing-complete, non-lambda combinator function. The function
6969takes a cell `{subject formula}`, and produces a noun `product`.
7070
7171To 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).
7373
7474## Compilation concepts
7575
@@ -81,6 +81,21 @@ expression (AST), and a `nock` is a Nock formula. `mint` accepts
8181a subject type and a source expression; it produces a product type
8282and an executable formula.
8383
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+
8499### `twig` (expression)
85100
86101A [`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
187202subtree of the subject. If it finds a core, it computes the arm
188203formula with that core as the subject.
189204
190−A limb can also be a slot (tree address), like `+15`, which
191−takes a leg directly.
205+A limb can also be a slot (direct tree address), like `+15`.
192206
193207### `wing` (limb path)
194208
docs/programming/hoon/demo.md+2−2
@@ -27,8 +27,8 @@ line is commented with its number:
2727:moar(count (add 1 count)) :: 15
2828```
2929
30−Can you understand this code by just looking at it? Hopefully,
31−but let's explain it anyway.
30+Can you understand this code by just looking at it? Maybe.
31+But let's explain it anyway.
3232
3333Hoon is a functional language. FizzBuzz is usually defined as a
3434side effect, but Hoon has no side effects. This code will
docs/programming/hoon/examples.md+2−1
@@ -1,6 +1,7 @@
11---
2−sort: 8
2+sort: 9
33title: Examples
4+next: true
45---
56
67# Examples
docs/programming/hoon/library.md+3−4
@@ -1,9 +1,8 @@
11---
2−sort: 12
3−title: Standard Library
2+sort: 11
3+title: Library
44---
55
6−Library
7−========
6+# Library
87
98<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
1313programming without category theory, formal logic, or other
1414interesting math. The reasoning: (a) a programming language is a
1515user interface for programmers; (b) most programmers are not very
16−good at math. Hoon is not quite as expressive as Haskell, though
17−fairly close.
16+good at math.
1817
19−Good Hoon style varies from good Haskell style. Hoon encourages
18+Hoon is not quite as expressive as Haskell, though fairly close.
19+But good Hoon style isn't good Haskell style. Hoon encourages
2020coders to use higher-order programming as little as possible --
2121again, simply for UI reasons. For example, multiple arguments
2222are 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
2525when we really need it. But we try not to swat flies with it.
2626
2727Hoon is objectively simple: its complexity is bounded by the size
28−of the compiler, about 3000 lines of Hoon. This is split about
29−halfway half between frontend (parsing and macro expansion) and
30−backend (code generation and type inference).
31−
32−This parser-heavy ratio reflects the belief that our brains are
33−better than everyone thinks at learning languages (symbols and/or
34−grammars), and worse at learning abstractions (proofs and/or
35−algorithms). At first glance, Hoon may look gnarly (though its
36−squiggles are more structured than most ASCII-heavy languages).
37−But there's 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.)
28+of the compiler, about 3000 lines of Hoon. This is split evenly
29+between frontend (parsing and macro expansion) and backend (code
30+generation and type inference).
31+
32+Compared to most languages, Hoon has a heavier front end (more
33+complex syntax) and a lighter back end (less complex semantics).
34+This ratio reflects the belief that our brains are better than
35+everyone thinks at learning languages (symbols and/or grammars),
36+and worse at learning abstractions (proofs and/or algorithms).
37+At first glance, Hoon may look gnarly (though its squiggles are
38+more structured than most ASCII-heavy languages). But there's
39+less than you might expect under the hood.
4440
4541Keeping the Hoon-to-Nock mapping straightforward is a priority.
4642Very 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 @@
11---
2−sort: 9
2+sort: 8
33title: Troubleshooting
4+next: true
45---
56
67# Troubleshooting
docs/programming/hoon/twig.md+12−8
@@ -1,13 +1,14 @@
11---
2−sort: 7
2+sort: 6
33next: true
4−title: Expressions: twig
4+title: Expressions
55---
66
7−# Expression: `twig`
7+# Expressions
88
9−A `twig` is an AST node: the noun that the Hoon compiler makes
10−when it parses a source expression.
9+A Hoon expression is called a `twig`. A `twig` is an AST node:
10+the noun that the Hoon compiler makes when it parses a source
11+expression.
1112
1213The definition of `twig` is the definition of Hoon. So let's
1314define 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.
3738
3839Twigs are described as *mossy* (or *moldy*) and *seedy*; an
3940example 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−is always `%foo` (seedy). (Obviously, seed is *yang* and moss is
42−*yin*, so we can also say "yang foo" or "yin foo".)
41+mossy form.
42+
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]`.
4347
4448## Twig categories
4549
docs/programming/hoon/twig/atom.md+2−1
@@ -1,5 +1,6 @@
11---
2−sort: 2
2+sort: 1
3+next: true
34---
45
56# 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 @@
11---
2−sort: 3
2+sort: 2
3+next: true
34---
45
56# 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 @@
11---
2−sort: 5
2+sort: 13
3+next: true
34---
45
5−# `. dot` (nock)
6+# Special tools (`!` runes).
67
7−##### Run some nock.
8+## Twigs
89
910<list dataPreview="true" className="runes" linkToFragments="true"></list>
1011
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.