@@ -43,7 +43,7 @@ number. Thus, the keys of `q.tad` are a subset of the numbers less than
4343`jav` is the cache of previously-solved problems. The keys are a pair of
4444a term (either `%hood`, `%slap`, or `%slam`) and a noun that represents
4545the exact problem solved. In the case of a `%hood`, then, the key is of
46−the form `[%hood beam cage]`. For `%slap`, there is `[%slap vase twig]`.
46+the form `[%hood beam cage]`. For `%slap`, there is `[%slap vase hoon]`.
4747For `%slam`, there is `[%slam vase vase]`. The values are the result of
4848solving the problem. Note that this cache is wiped in `++stay` when ford
4949is reloaded.
@@ -79,7 +79,7 @@ stored by index in `q.kig`, and the next available index is `p.kig`.
7979 [%pact p=silk q=silk] :: patch
8080 [%plan p=beam q=spur r=hood] :: structured assembly
8181 [%reef ~] :: kernel reef
82− [%ride p=twig q=silk] :: silk thru twig
82+ [%ride p=hoon q=silk] :: silk thru hoon
8383 [%vale p=mark q=ship r=*] :: validate [our his]
8484 == ::
8585
@@ -95,7 +95,7 @@ discussion of the public interface to ford below.
9595
9696 ++ calx :: concrete cache line
9797 $% [%hood p=calm q=(pair beam cage) r=hood] :: compile
98− [%slap p=calm q=[p=vase q=twig] r=vase] :: compute
98+ [%slap p=calm q=[p=vase q=hoon] r=vase] :: compute
9999 [%slam p=calm q=[p=vase q=vase] r=vase] :: compute
100100 == ::
101101
@@ -106,7 +106,7 @@ The input to a `%hood` is the location of the resource and a cage
106106representing the data at that location. The output is the hood found by
107107compiling the given cage at the given location.
108108
109−The input to a `%slap` is the vase of the subject and the twig of the
109+The input to a `%slap` is the vase of the subject and the hoon of the
110110formula against which we are slapping the subject. The output is the
111111vase produced by slapping them.
112112
@@ -158,7 +158,7 @@ subject of the body with a `=>`.
158158different ways and may load resources from any location. These are
159159placed in the subject of the body with a `=~`.
160160
161−`src` is the set of twigs or references to twigs in the body of the
161+`src` is the set of hoons or references to hoons in the body of the
162162program. Generally, each of these will represent a core, but this is not
163163required. When compiling, these are strung together in a `=~`.
164164
@@ -181,8 +181,8 @@ retrieve it from.
181181### `++horn`
182182
183183 ++ horn :: resource tree
184− $% [%ape p=twig] :: /~ twig by hand
185− [%arg p=twig] :: /$ argument
184+ $% [%ape p=hoon] :: /~ hoon by hand
185+ [%arg p=hoon] :: /$ argument
186186 [%day p=horn] :: /| list by @dr
187187 [%dub p=term q=horn] :: /= apply face
188188 [%fan p=(list horn)] :: /. list
@@ -191,7 +191,7 @@ retrieve it from.
191191 [%man p=(map span horn)] :: /* hetero map
192192 [%nap p=horn] :: /% homo map
193193 [%now p=horn] :: /& list by @da
194− [%saw p=twig q=horn] :: /; operate on
194+ [%saw p=hoon q=horn] :: /; operate on
195195 [%see p=beam q=horn] :: /: relative to
196196 [%sic p=tile q=horn] :: /^ cast
197197 [%toy p=mark] :: /mark/ static
@@ -202,7 +202,7 @@ discussion of their use from a user's perspective is documented in the [runes
202202documentation](https://urbit.org/docs/arvo/internals/runes), so we will here
203203only give a description of the data structure itself.
204204
205−A `%ape` horn is simply a twig that gets evaluated and placed in the
205+A `%ape` horn is simply a hoon that gets evaluated and placed in the
206206subject.
207207
208208A `%arg` is a gate that gets evaluated with a sample of our location and
@@ -232,7 +232,7 @@ with the same horn and is given a face according to its name.
232232A `%now` is a horn that applies to each of a list of `@da`-named files
233233in the directory.
234234
235−A `%saw` is a twig and a horn, where the twig operates on the result of
235+A `%saw` is a hoon and a horn, where the hoon operates on the result of
236236the horn.
237237
238238A `%see` is a beam and a horn, where the horn is evaluated at a location
@@ -246,7 +246,7 @@ A `%toy` is simply a mark to be baked.
246246### `++hoop`, body
247247
248248 ++ hoop :: source in hood
249− $% [%& p=twig] :: direct twig
249+ $% [%& p=hoon] :: direct hoon
250250 [%| p=beam] :: resource location
251251 == ::
252252
@@ -358,7 +358,7 @@ There are twelve possible computations defined in `++silk`.
358358 [%mute p=silk q=(list (pair wing silk))] :: mutant
359359 [%plan p=beam q=spur r=hood] :: structured assembly
360360 [%reef ~] :: kernel reef
361− [%ride p=twig q=silk] :: silk thru twig
361+ [%ride p=hoon q=silk] :: silk thru hoon
362362 [%vale p=mark q=ship r=*] :: validate [our his]
363363 == ::
364364
@@ -409,7 +409,7 @@ functionality. We don't usually have naked hoods outside ford.
409409`%reef` produces a core containing the entirety of zuse and hoon,
410410suitable for running arbitrary code against. The mark is `%noun`.
411411
412−`%ride` slaps a twig against a subject silk. The mark of the result is
412+`%ride` slaps a hoon against a subject silk. The mark of the result is
413413`%noun`.
414414
415415`%vale` validates untyped data from a ship against a given mark. This is
@@ -481,7 +481,7 @@ Fourth, we may have zero or more other `/` runes (as described in
481481`++horn`), which represent program-specific resources to be loaded.
482482
483483Fifth and finally, we must have one or more body statements (hoops),
484−which are either direct twigs or `//` runes.
484+which are either direct hoons or `//` runes.
485485
486486 ++ hoot
487487 ;~ pose
@@ -491,7 +491,7 @@ which are either direct twigs or `//` runes.
491491
492492A structure can either be a direct gate, or it can be a simple core.
493493Either one is parsed with `++hoof`, so we distinguish the two cases by
494−requireing core references to be prefixed by a `*`.
494+requiring core references to be prefixed by a `*`.
495495
496496 ++ hoof
497497 %+ cook |=(a=^hoof a)
@@ -529,10 +529,10 @@ parse, so we'll discuss those first.
529529 (stag %& tall:vez)
530530 ==
531531
532−There are two types of hoops. Direct twigs are parsed with
533−`++tall:vast`, which is the just the hoon parser for a tall-form twig.
532+There are two types of hoops. Direct hoons are parsed with
533+`++tall:vast`, which is the just the Hoon parser for a tall-form rune.
534534
535−References to external twigs are marked with a `//` rune followed by a
535+References to external hoons are marked with a `//` rune followed by a
536536beam, which is parsed with `++have`.
537537
538538 ++ hath (sear plex:voz (stag %clsg poor:voz)) :: hood path
@@ -600,9 +600,9 @@ the wide form rule.
600600 ;~(pfix gap tall:vez)
601601
602602`++ape:read` parses for both the `/~` and the `/$` runes. It produces a
603−twig. The wide form is a tuple of one or more ace-separated wide-form
604−twigs parsed with `++wide:vast` and surrounded by `[` and `]`. The tall
605−form is a single tall form twig parsed by `++tall:vast`
603+hoon. The wide form is a tuple of one or more ace-separated wide-form
604+hoons parsed with `++wide:vast` and surrounded by `[` and `]`. The tall
605+form is a single tall form hoon parsed by `++tall:vast`
606606
607607 ++ day
608608 %+ rail
@@ -665,10 +665,10 @@ horn is inserted into the produced map as a key-value pair.
665665 ;~(plug ;~(sfix wide:vez sem) apex(tol |))
666666 ;~(pfix gap ;~(plug tall:vez ;~(pfix gap apex)))
667667
668−This parses for the `/;` rune. It produces a twig and a horn. The wide
669−form is a wide-form twig followed by a `;` and, recursively, the entire
668+This parses for the `/;` rune. It produces a hoon and a horn. The wide
669+form is a wide-form hoon followed by a `;` and, recursively, the entire
670670horn parser with tall form disabled. The tall form is a gap followed by
671−a tall-form twig, another gap, and, recursively, the entire horn parser.
671+a tall-form hoon, another gap, and, recursively, the entire horn parser.
672672
673673 ++ see
674674 %+ rail
@@ -701,12 +701,12 @@ assembling is handled entirely within the `++meow:zo:za` core.
701701
702702 ++ meow :: assemble
703703 |= [how=beam arg=heel]
704− =| $: rop=(map term (pair hoof twig)) :: structure/complex
704+ =| $: rop=(map term (pair hoof hoon)) :: structure/complex
705705 zog=(set term) :: structure guard
706− bil=(map term (pair hoof twig)) :: libraries known
706+ bil=(map term (pair hoof hoon)) :: libraries known
707707 lot=(list term) :: library stack
708708 zeg=(set term) :: library guard
709− boy=(list twig) :: body stack
709+ boy=(list hoon) :: body stack
710710 hol=? :: horns allowed?
711711 ==
712712 |%
@@ -715,7 +715,7 @@ We take two arguments and keep seven pieces of state. `how` is the
715715location of the hook file we're assembling, and `arg` is the heel, or
716716virtual path extension, of the file.
717717
718−In `rop`, we maintain a map of terms to pairs of hooves and twigs to
718+In `rop`, we maintain a map of terms to pairs of hooves and hoons to
719719represent the structures we've encountered that we will put together in
720720a core at the top of the file.
721721
@@ -724,7 +724,7 @@ loading. If we try to load a structure already in our dependency
724724ancestry, then we fail because we do not allow circular dependencies.
725725This enforces that our structure dependency graph is a DAG.
726726
727−In `bil`, we maintain a map of terms to pairs of hooves and twigs to
727+In `bil`, we maintain a map of terms to pairs of hooves and hoons to
728728represent the libraries we've encountered that we will put together in a
729729series of cores after the structure core.
730730
@@ -740,7 +740,7 @@ loading. If we try to load a library already in our dependency ancestry,
740740then we fail because we do not allow circular dependencies. This
741741enforces that our library dependency graph is a DAG.
742742
743−In `boy`, we maintain a stack of body twigs, which we'll put together in
743+In `boy`, we maintain a stack of body hoons, which we'll put together in
744744a series of cores at the end of the file.
745745
746746In `hol`, we decide if we're allowed to contain horns. Libraries and
@@ -823,7 +823,7 @@ this is that it does essentially five things.
823823First, we call `++apex` to process the structures, libraries, and body.
824824This changes our state, so we set our context to the produced context.
825825Second, we call `++able` to assemble the strucutres and libraries into a
826−twig, which we slap against zuse with `++maim`. Third, we call `++chap`
826+hoon, which we slap against zuse with `++maim`. Third, we call `++chap`
827827to process the resources in the context of the already-loaded structures
828828and libraries. Fourth, we slap the body against the structures,
829829libraries, and resources. Fifth and finally, we produce the resultant
@@ -916,7 +916,7 @@ individual hoop and recurse.
916916 (fine cof sel(boy [[%brcn mav] boy]))
917917 ==
918918
919−In the case of a direct twig hoop, we just push it onto `boy` and we're
919+In the case of a direct hoon hoop, we just push it onto `boy` and we're
920920done. In the case of an indirect hoop, we must compile the referenced
921921file.
922922
@@ -958,8 +958,8 @@ we are accumulating all the structures and libraries referenced in all
958958the referenced hook files in one group, which we will put at the top of
959959the product.
960960
961−After this, we put the new list of body twigs into a `=~`, push this
962−onto our old list of body twigs, and produce the result.
961+After this, we put the new list of body hoons into a `=~`, push this
962+onto our old list of body hoons, and produce the result.
963963
964964If there is no hoon file here, then we descend into each of our children
965965until we find a hoon file. First, we produce a list of all our children
@@ -986,8 +986,8 @@ those children whose names are not terms.
986986Next, we will produce a map from terms to feet. Each of these feet will
987987be placed in a core named by the child name, and it will contain arms
988988according to its children. Thus, if the indirect hoop references
989−`/path`, then to access the twig defined in `/path/to/twig/hoon`, our
990−body must refer to `twig:to`.
989+`/path`, then to access the hoon defined in `/path/to/hoon/hoon`, our
990+body must refer to `hoon:to`.
991991
992992If there are no more children, then we are done, so we produce our
993993current context.
@@ -1004,7 +1004,7 @@ We also produce the new context so that all external structures,
10041004libraries, and resources are collected into the same place.
10051005
10061006Finally, we have a map of names to feet. If this map is empty, then
1007−there were no twigs at the requested path, so we give an error with
1007+there were no hoons at the requested path, so we give an error with
10081008`++flaw`.
10091009
10101010If the map is nonempty, then we finally produce our context with with
@@ -1080,7 +1080,7 @@ that it takes a beam and parses the hook file there into a hood.
10801080We recurse on this to compile the library. During the compilation, we
10811081let `zeg` be `gez` to avoid circular dependencies, we let `hol` be false
10821082since we don't allow horns in libraries, and we let `boy` be null so
1083−that we can isolate the new body twigs.
1083+that we can isolate the new body hoons.
10841084
10851085Next, we reintegrate the new data into our context. We use the context
10861086created by the recursion with four changes. First, we reset `zeg` to our
@@ -1088,7 +1088,7 @@ old `zeg`. Second, we reset `hol` to our old `hol`. Third, we put the
10881088name of our library onto the stack of libraries. This means all of a
10891089libraries dependencies will be earlier in `lot` than the library itself,
10901090making `lot` a topological ordering on the dependency graph. Fourth, we
1091−put in `bil` the library hoof and body (with all body twigs collected in
1091+put in `bil` the library hoof and body (with all body hoons collected in
10921092a `=~`), keyed by the library name.
10931093
10941094Finally, we recurse, processing the next library in our list.
@@ -1135,7 +1135,7 @@ structures to process. If not, we're done, so we produce our context.
11351135
11361136Otherwise, we let `goz` be `zog` plus the current structure so that
11371137while compiling the dependencies of this structure we don't later create
1138−a circular dependency. We check next to see if this structure is alredy
1138+a circular dependency. We check next to see if this structure is already
11391139in `rop`. If so, then we have already included this structure earlier,
11401140so we check to see if this is the same version of the structure as we
11411141included earlier. If so, we skip it. Else, we fail since we can't
@@ -1147,19 +1147,19 @@ true, then we're looking for a gate; otherwise, we're looking for a
11471147core. We parse this file with `++fade`.
11481148
11491149Now, we recurse on this to compile the structure. During the recursion,
1150−there we have threee changes. Frist, we let `zog` be `goz` so that we
1150+there we have three changes. Frist, we let `zog` be `goz` so that we
11511151don't create a circular dependency. Second, we let `hol` be false since
11521152we do not allow horns in structures. Third, we let `boy` be null so that
1153−we can isolate the new body twigs.
1153+we can isolate the new body hoons.
11541154
11551155Next, we reintegrate the new data into our context. We use the context
11561156cretaed by the recursion with four changes. First, if we're including a
11571157gate structure, then we reset the body to its original body. Else we put
1158−on the top of our list of body twigs what is essentially a
1158+on the top of our list of body hoons what is essentially a
11591159`=+ structure-name` to take off the face of the structure. Second, we
11601160reset `zog` to our old `zog`. Third, we reset `hol` to our old `hol`.
11611161Finally, we put in `rop` the structure hoof and body (with all body
1162−twiggs collected in a `=~`), keyed by the structure name.
1162+hoongs collected in a `=~`), keyed by the structure name.
11631163
11641164Finally, we recurse, processing the next structure in our list.
11651165
@@ -1180,13 +1180,13 @@ This concludes our discussion of `++apex`.
11801180 (fine cof fin)
11811181
11821182Returning to `++abut`, we have now processed the structures, libraries
1183−and body twigs. Next, we slap our preamble (structures and libraries)
1183+and body hoons. Next, we slap our preamble (structures and libraries)
11841184against zuse. First, we construct our preamble in `++able`.
11851185
11861186 ++ able :: assemble preamble
1187− ^- twig
1187+ ^- hoon
11881188 :+ %tsgr
1189− ?:(=(~ rop) [%$ 1] [%brcn (~(run by rop) |=([* a=twig] [%ash a]))])
1189+ ?:(=(~ rop) [%$ 1] [%brcn (~(run by rop) |=([* a=hoon] [%ash a]))])
11901190 [%tssg (turn (flop lot) |=(a=term q:(need (~(get by bil) a))))]
11911191
11921192We first put the structures in `rop` into a single `|%` at the top and
@@ -1197,10 +1197,10 @@ libraries are in consecutive cores.
11971197We slap the preamble against zuse with `++maim`.
11981198
11991199 ++ maim :: slap
1200− |= [cof=cafe vax=vase gen=twig]
1200+ |= [cof=cafe vax=vase gen=hoon]
12011201 ^- (bolt vase)
12021202 %+ (clef %slap) (fine cof vax gen)
1203− |= [cof=cafe vax=vase gen=twig]
1203+ |= [cof=cafe vax=vase gen=hoon]
12041204 =+ puz=(mule |.((~(mint ut p.vax) [%noun gen])))
12051205 ?- -.puz
12061206 | (flaw cof p.puz)
@@ -1215,7 +1215,7 @@ is not already in our cache. First we'll discuss the computation, then
12151215we'll discuss the caching system.
12161216
12171217We call `++mule` with a call to `++mint:ut` on the type of our subject
1218−vase against the given twig. In other words, we're compiling the twig
1218+vase against the given hoon. In other words, we're compiling the hoon
12191219with against the subject type in the given subject vase.
12201220
12211221If compilation fails, then we produce an error bolt with the produced
@@ -1343,14 +1343,14 @@ through them one by one.
13431343 ?- -.hon
13441344 %ape (maim cof bax p.hon)
13451345
1346−This is `/~`. We slap the twig against our context.
1346+This is `/~`. We slap the hoon against our context.
13471347
13481348 %arg
13491349 %+ cope (maim cof bax p.hon)
13501350 |= [cof=cafe gat=vase]
13511351 (maul cof gat !>([how arg]))
13521352
1353−This is `/$`. We slap the twig against our context, which we expect to
1353+This is `/$`. We slap the hoon against our context, which we expect to
13541354produce a gate. We slam this gate with a sample of `how` and `arg`,
13551355which is our location and the heel (virtual path extension).
13561356
@@ -1549,7 +1549,7 @@ This is `/:`. We process the given horn at the given beam.
15491549 (maul cof gat sam)
15501550
15511551This is `/;`. First, we process the given horn. Then, we slap the given
1552−twig against our context to produce (hopefully) a gate. Finally, we slam
1552+hoon against our context to produce (hopefully) a gate. Finally, we slam
15531553the vase we got from processing the horn against the gate.
15541554
15551555 %sic
@@ -1599,12 +1599,12 @@ We return once more to `++abut`.
15991599 |= [cof=cafe gox=vase]
16001600 %+ cope (maim cof (slop gox bax) [%tssg (flop boy)])
16011601 |= [cof=cafe fin=vase]
1602− (fine cof fin)
1602+ (fine cof fin)
16031603
16041604Recall that we processed our structures, libraries and body with
16051605`++apex`. We slapped our structures and libraries against zuse with
16061606`++maim`. We processed our resources with `++chap`. Now, all our body
1607−twigs are collected in a `=~` and slapped against our structures,
1607+hoons are collected in a `=~` and slapped against our structures,
16081608libraries, and resources. This produces our final result.
16091609
16101610The hook file has been assembled. And there was great rejoicing.
@@ -2346,23 +2346,23 @@ of the main silk, so we mark the produced vase with the original mark.
23462346 ++ keel :: apply mutations
23472347 |= [cof=cafe suh=vase yom=(list (pair wing vase))]
23482348 ^- (bolt vase)
2349− %^ maim cof
2349+ %^ maim cof
23502350 %+ slop suh
23512351 |- ^- vase
23522352 ?~ yom [[%atom %n] ~]
23532353 (slop q.i.yom $(yom t.yom))
2354− ^- twig
2354+ ^- hoon
23552355 :+ %cncb [%& 2]~
23562356 =+ axe=3
2357− |- ^- (list (pair wing twig))
2357+ |- ^- (list (pair wing hoon))
23582358 ?~ yom ~
23592359 :- [p.i.yom [%$ (peg axe 2)]]
23602360 $(yom t.yom, axe (peg axe 3))
23612361
23622362We first put the vases together in one big tuple starting with the
23632363subject and going through the mutations. We slap against this tuple a
2364−`%_` twig we directly construct. Since a `%_` twig takes a list of pairs
2365−of wings and twigs, we simply have to generate twigs referring to the
2364+`%_` hoon we directly construct. Since a `%_` hoon takes a list of pairs
2365+of wings and hoons, we simply have to generate hoons referring to the
23662366correct axes in the subject. This is very easy since we just recur on
23672367axis 3 of whatever axis we were already at.
23682368
@@ -2483,7 +2483,7 @@ Lifcycle of a `%ride`
24832483 (fine cof %noun vax)
24842484
24852485This slaps evaluates the given silk, then it slaps the result against
2486−the given twig. Since we don't know what of what mark (if any) is the
2486+the given hoon. Since we don't know what of what mark (if any) is the
24872487result, we give it a mark of `%noun`.
24882488
24892489Lifecycle of a `%vale`
@@ -2532,7 +2532,7 @@ At any rate, `++lake` coerces a noun into the correct type for a mark.
25322532 (flaw cof [%leaf "ford: no noun: {<[for bek]>}"]~)
25332533 %+ cope (maul cof (slap gab [%cnzy %noun]) [%noun q.sam])
25342534 |= [cof=cafe pro=vase]
2535− ?: =(+<.q.pro q.sam)
2535+ ?: =(+<.q.pro q.sam)
25362536 (fine cof (slot 6 pro))
25372537 (flaw cof [%leaf "ford: invalid content: {<[for bek]>}"]~)
25382538