356ec9a · urbit.org · git.iko.soy

git.iko.soy/urbit.org

fixes to ch 1

commit356ec9a93355a20b9e66f975605df2a98a92d294 authorjoshuareagan <josh@tlon.io> dateWed 12 Dec 2018, 14:26 (8 years ago) parent7b25e0b

3 files changed+94−127

compare with master

unifiedsplit

docs/tutorials/hoon-ch1/hoon-ch1-4.udon+2−2 docs/tutorials/hoon-ch1/hoon-ch1-5.udon+36−60 docs/tutorials/hoon-ch1/hoon-ch1-6.udon+56−65

docs/tutorials/hoon-ch1/hoon-ch1-4.udon+2−2

@@ -77,7 +77,7 @@ A battery is a collection of arms. An arm is an encoded Hoon expression, to be

7777

7878That's all you really need to know about the battery. You can become a master Hoon programmer if you know what is stated above but otherwise think of the battery as a black box.

7979

80−But, if you'd really like to know, technically a battery is a tree of Nock formulas, one formula per each arm. Again, however, you don't need to understand the first thing about Nock to understand Hoon.

80+If you'd really like to know, technically a battery is a tree of Nock formulas, one formula per each arm. Again, however, you don't need to understand the first thing about Nock to understand Hoon.

8181

8282### Payload

8383

@@ -87,7 +87,7 @@ The payload may include other cores. Consequently, a core's payload can include

8787

8888### Subject Organization for Arm Computation

8989

90−Why must an arm have its parent core as the subject, when it's computed? As stated previously, the payload of a core contains all the data needed for computing the arms of that core. Arms can only access data in the subject. By requiring that the parent core be the subject we guarantee that each arm has the appropriate data available to it, in the tail of the subject. It also allows for making reference to sibling arms in the battery, because they are in the head of the subject.

90+Why must an arm have its parent core as the subject, when it's computed? As stated previously, the payload of a core contains all the data needed for computing the arms of that core. Arms can only access data in the subject. By requiring that the parent core be the subject we guarantee that each arm has the appropriate data available to it. The tail of its subject contains the payload and thus all the values therein. The head of the subject is the battery, which allows for making reference to sibling arms of that same core.

9191

9292Let's look at an example in which the payload information is needed for correct arm evaluation.

9393

docs/tutorials/hoon-ch1/hoon-ch1-5.udon+36−60

@@ -2,13 +2,21 @@

22 navuptwo/'true'

33 next/'true'

44 sort/'5'

5− title/'1.5 Gates and Hoon Functions'

5+ title/'1.5 Gates (Hoon Functions)'

66 ==

77;>

9−# 1.5 Gates and Hoon Functions

9+# 1.5 Gates (Hoon Functions)

1010

11−In this lesson you're going to learn about Hoon functions. A mathematical function takes an input value and returns an output value; and the value of the latter depends solely upon the value of the former. (The latter property of functions is called [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency).) To implement a function in Hoon, use a special kind of core called a *gate*. In this lesson you'll learn what a gate is and how a gate represents a function. Along the way you'll build some example gates of your own.

11+In this lesson you're going to learn about Hoon functions.

12+

13+## What is a Function?

14+

15+The word 'function' is used in various ways, but let's start by talking about them in the [mathematical sense](https://en.wikipedia.org/wiki/Function_(mathematics%29). Roughly put, a function takes one or more arguments (i.e., input values) and returns a value. What the return value is depends solely on the argument(s), and nothing else. For example, we can understand multiplication as a function: it takes two numbers and returns another number. It doesn't matter where you ask, when you ask, or what kind of hat you're wearing when you ask. If you pass the same two numbers (e.g., `3` and `4`), you get the same answer returned every time (`12`).

16+

17+That output value depends solely upon input value(s) is an important property of functions. This property is called [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency), and we make use of it throughout the Urbit software stack.

18+

19+Functions are implemented in Hoon with a special kind of core called a *gate*. In this lesson you'll learn what a gate is and how a gate represents a function. Along the way you'll build some example gates of your own.

1220

1321You've already used two functions from the Hoon standard library: `add` and `mul`. These are implemented with gates, and you call them from the dojo in the following way:

1422

@@ -24,14 +32,12 @@ You've already used two functions from the Hoon standard library: `add` and `mul

2432

2533A core is a cell: `[battery payload]`.

2634

27−A gate is a core, but it's not just any core. It has two distinctive properties: (1) the battery of a gate contains exactly one arm, which has the special name `$`. The `$` arm contains the instructions for the function in question. And (2), the payload of a gate consists of a cell of `[sample context]`. The sample is the part of the payload that stores the 'argument' (i.e., input value) of the function call. The context contains all other data that is needed for computing the `$` arm of the gate correctly.

35+A gate is a core with two distinctive properties: (1) the battery of a gate contains exactly one arm, which has the special name `$`. The `$` arm contains the instructions for the function in question. And (2), the payload of a gate consists of a cell of `[sample context]`. The sample is the part of the payload that stores the 'argument' (i.e., input value) of the function call. The context contains all other data that is needed for computing the `$` arm of the gate correctly.

2836

2937```

30−A gate: [$ [sample context]]

38+Gate: [$ [Sample Context]]

3139```

3240

33−To reiterate, the `$` arm is the code for producing the output value, the sample is the input value, and the context is any other data necessary for `$` to run correctly.

34−

3541As a tree, a gate looks like the following:

3642

3743```

@@ -46,22 +52,6 @@ Like all arms, `$` is computed with its parent core as the subject. When `$` is

4652

4753## Creating Your First Gate

4854

49−Before making a gate, let's take a look at the dojo subject so we can refer to it later:

50−

51−```

52−> .

53−[ [ our=~bitnus-holleb-rocmeg-fotfer--migsum-nidsym-hilput-patmus

54− now=~2018.8.21..22.03.05..a444

55− eny

56− \/0v1hp.ug5b7.i21p4.qd4bt.0cc08.ug5og.j2uru.05a5a.pk3j5.vascn.mudri.pghpu.t\/

57− 6vs7.h8pg0.ivnr7.smav1.rhova.ang41.347of.l1ahv.vfdvh

58− \/ \/

59− ]

60− ~

61− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

62−]

63−```

64−

6555Let's make a gate that takes any unsigned integer (i.e., an atom) as its sample and returns that value plus one as the product. To do this we'll use the `|=` rune. We'll bind this gate to the face `inc` for 'increment':

6656

6757```

@@ -81,45 +71,42 @@ The gate works as promised -- it takes any number `n` and returns `n + 1`. Let'

8171

8272### The `|=` Rune

8373

84−We can use `|=` to create a gate. There are two subexpressions that go after a `|=` rune. The first defines the gate's sample, and the second defines the gate's product.

74+We typically use the `|=` rune to create a gate. In the expression above the `|=` is immediately followed by a set of parentheses containing two subexpressions: `a=@` and `(add 1 a)`. The first defines the gate's sample (input value type), and the second defines the gate's product (value).

8575

86−In the example gate above, `inc`, the sample is defined by `a=@`. This means that the sample is defined as an atom, `@`, and it is given the face `a`. With the face it's easier to refer to the sample in later code, if desired.

76+When we used the `|%` rune in the last lesson we didn't use parentheses because we were writing in "tall form" syntax, whereas here we are writing in "flat form" syntax. (The latter uses parentheses and is more suitable for shorter snippets of code.) We'll explain these concepts more thoroughly in lesson 2.2.

77+

78+In the example gate above, `inc`, the sample is defined by `a=@`. This means that the sample is defined as an atom, `@`, meaning that the gate will take as input anything of that type. The sample is given the face `a`. With the face it's easier to refer to the sample in later code, if desired.

8779

8880In `inc`, the product is defined by `(add 1 a)`. There's not much to it -- it returns the value of `a + 1`!

8981

90−The second subexpression after the `|=` rune is used to build the gate's `$` arm. That's where all the computations go. The sample is defined by the first subexpression.

82+The second subexpression after the `|=` rune is used to build the gate's `$` arm. That's where all the computations go.

83+

84+## Anatomy of a Gate

9185

92−The context of the resulting gate is a copy of the subject for the `|=` expression. To see this, let's print the value of `inc` in the dojo:

86+A gate is a one-armed core with a sample: `[$ [Sample Context]]`. Let's go over these parts a little more carefully, using `inc` as our example.

9387

9488```

9589> inc

96−< 1.viz

90+< 1.jgn

9791 { a/@

9892 {our/@p now/@da eny/@uvJ}

99− $~

100− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

93+ <19.anu 24.tmo 6.ipz 38.ard 119.spd 241.plj 51.zox 93.pqh 74.dbd 1.qct $141>

10194 }

10295>

10396```

10497

105−The `1.viz` represents the `$` arm of the gate. The `a/@` is for the sample. And the rest is the dojo subject that was used for the `|=` expression. (Compare it to the dojo subject we printed before binding `inc` to a gate -- it's pretty printed in a slightly different way, but it's the same noun.)

106−

107−## Anatomy of a Gate

108−

109−A gate is a one-armed core with a sample: `[$ [sample context]]`. Let's go over these parts a little more carefully, using `inc` as our example.

110−

11198### The `$` Arm

11299

113−The arm of a gate specifies (in Nock) the instructions for the Hoon function in question. The gate's arm is always located at `+2` of the gate.

100+The arm of a gate encodes the instructions for the Hoon function in question.

114101

115−The pretty printer represents the `$` arm of `inc` as `1.viz`. To see the actual noun of the `$` arm, enter `+2:inc` into the dojo:

102+The pretty printer represents the `$` arm of `inc` as `1.jgn`. To see the actual noun of the `$` arm, enter `+2:inc` into the dojo:

116103

117104```

118105> +2:inc

119106[8 [9 8 0 4.095] 9 2 [0 4] [[7 [0 3] 1 1] 0 14] 0 11]

120107```

121108

122−Here we see a Nock formula. For what it's worth, these are the Nock instructions for adding `1` to a number. (Again, you don't need to understand how to read Nock.)

109+This is un-computed Nock. You don't need to understand any of this.

123110

124111It's worth pointing out that the arm name, `$`, can be used like any other name. We can compute `$` directly with `$:add` in the dojo:

125112

@@ -138,11 +125,10 @@ Let's look at the gate for `inc` again, paying particular attention to its sampl

138125

139126```

140127> inc

141−< 1.viz

128+< 1.jgn

142129 { a/@

143130 {our/@p now/@da eny/@uvJ}

144− $~

145− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

131+ <19.anu 24.tmo 6.ipz 38.ard 119.spd 241.plj 51.zox 93.pqh 74.dbd 1.qct $141>

146132 }

147133>

148134```

@@ -173,19 +159,18 @@ Let's look at the context of `inc`:

173159

174160```

175161> +7:inc

176−[ [ our=~bitnus-holleb-rocmeg-fotfer--migsum-nidsym-hilput-patmus

177− now=~2018.8.21..22.13.52..828a

162+[ [ our=~zod

163+ now=~2018.12.12..18.55.06..df2b

178164 eny

179− \/0v3ui.rq2no.g0eor.f0kjq.njfr4.tlb60.fq340.cvfh5.p4168.rj3r2.pr5d2.0532k.h\/

180− ite1.r218h.ukqle.cldnl.0e5h5.9pvkm.rhep5.ole0s.hbann

181− \/ \/

165+ \/0v2g0.cmm6d.1igpo.llg7o.4921d.nov38.vjsgp.mdfln.8pt9f.n23hj.qc6q9.8p7bd\/

166+ .2eo59.qko43.1jgd2.rtc44.egooe.esvft.orohc.i9ufn.4rnur

167+ \/ \/

182168 ]

183− ~

184− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

169+ <19.anu 24.tmo 6.ipz 38.ard 119.spd 241.plj 51.zox 93.pqh 74.dbd 1.qct $141>

185170]

186171```

187172

188−You can see that this is exactly the subject before we put `inc` into the subject.

173+This is exactly the default dojo subject, from before we put `inc` into the subject. The `|=` expression defines the context as whatever the subject is. This guarantees that the context has all the information it needs to have for the `$` arm to work correctly.

189174

190175### Exercise 1.5.1

191176

@@ -193,7 +178,7 @@ Write a gate that takes an atom, `a=@`, and which returns double the value of `a

193178

194179## Gates Define Functions of the Sample

195180

196−The value of a function's output depends solely upon the input value. This is one of the features that make functions desirable in many programming contexts. It's worth going over how Hoon function calls implement this feature. Let's talk about how function calls work in Hoon.

181+The value of a function's output depends solely upon the input value. This is one of the features that make functions desirable in many programming contexts. It's worth going over how Hoon function calls implement this feature.

197182

198183In Hoon one can use `(gate arg)` syntax to make a function call. For example,

199184

@@ -254,15 +239,6 @@ We can unbind `b` from the dojo subject, and `ten` works just as well because it

254239> (ten 35)

25524045

256241

257−> ten

258−< 1.umt

259− { a/@

260− {b/@ud our/@p now/@da eny/@uvJ}

261− $~

262− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

263− }

264−>

265−

266242> b.+7.ten

26724310

268244```

docs/tutorials/hoon-ch1/hoon-ch1-6.udon+56−65

@@ -1,11 +1,11 @@

11:- :~ navhome/'/docs/'

22 navuptwo/'true'

33 sort/'6'

4− title/'1.6 Producing Gates with Core Arms'

4+ title/'1.6 Multi-gate Cores and Doors'

55 ==

66;>

8−# 1.6 Producing Gates with Core Arms

8+# 1.6 Multi-gate Cores and Doors

1010It's useful to have cores whose arms evaluate to make gates. The use of such cores is common in Hoon; that's how the functions of the Hoon standard library are stored in the subject. Learning about such cores will also deepen the reader's understanding of Hoon semantics, and for that reason alone is worthwhile.

1111

@@ -21,26 +21,6 @@ There are two ways of making a function call in Hoon. First, you can call a gat

2121> (inc 10)

222211

2323

24−> .

25−[ [ inc

26− < 1.viz

27− { a/@

28− {our/@p now/@da eny/@uvJ}

29− $~

30− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

31− }

32− >

33− our=~bitnus-holleb-rocmeg-fotfer--migsum-nidsym-hilput-patmus

34− now=~2018.8.24..05.51.53..97b9

35− eny

36− \/0v3vd.sdp3o.ds8eq.5mr1s.du2v6.4a12r.poie2.04123.jaq8r.8qoum.mvb63.dblf7.7\/

37− lt1d.fqebb.pv6dr.lio19.re7lq.016q3.u03ne.c8aiu.7148p

38− \/ \/

39− ]

40− ~

41− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

42−]

43−

4424> =inc

4525```

4626

@@ -54,6 +34,8 @@ The second way of making a function call involves an expression that _produces_

5434246

5535```

5636

37+The difference is that `inc` is an already-created gate in the subject when we called it. The latter calls involve producing a gate that doesn't exist anywhere in the subject, and then calling it.

38+

5739Are calls to `add` and `mul` of the Hoon standard library of the first kind, or the second?

5840

5941```

@@ -64,9 +46,11 @@ Are calls to `add` and `mul` of the Hoon standard library of the first kind, or

6446276

6547```

6648

67−They're of the second kind. Neither `add` nor `mul` is a gate; they're each arms that _produce_ gates. Often the difference doesn't matter much. Either way you can do a function call using the `(gate arg)` syntax.

49+They're of the second kind. Neither `add` nor `mul` resolves to a gate directly; they're each arms that _produce_ gates.

50+

51+Often the difference doesn't matter much. Either way you can do a function call using the `(gate arg)` syntax.

6852

69−It's important to learn the difference, however, because for certain use cases you'll want the extra flexibility that comes with having an already produced core in the subject. This is particularly important when you want to mutate the core as you call it. It's far more straight-forward to mutate a core that already exists in the subject, than to have to produce it first and then mutate it.

53+It's important to learn the difference, however, because for certain use cases you'll want the extra flexibility that comes with having an already produced core in the subject.

7054

7155## A Gate-Building Core

7256

@@ -101,9 +85,9 @@ Notice that each arm in core `c` is able to call the other arms of `c` -- `add-t

10185

10286### The `..arm` Syntax

10387

104−Let's say you have a wing that resolves to a leg of the subject. In this wing is an arm name, e.g., `a.b.arm`. As you know from lesson 1.4, this should be read as '`a` in `b` in the parent core of `arm`'. Speaking more directly: the wing resolution path goes through the parent core of the arm, not the arm itself.

88+Let's say you have a wing that resolves to a leg of the subject. In this wing is an arm name, e.g., `a.b.arm`. As you learned in lesson 1.4, this should be read as '`a` in `b` in the parent core of `arm`'. Speaking more directly: the wing resolution path goes through the parent core of the arm, not the arm itself.

10589

106−Recall that `.` by itself returns the whole subject. With that in mind, take a moment to answer the following question on your own. In general, what should the expression `..arm` produce?

90+Recall that using `.` by itself returns the whole subject. With that in mind, take a moment to answer the following question on your own. In general, what should the expression `..arm` produce?

10791

10892Do you have an answer? If not, consider going back and trying to figure it out before moving on.

10993

@@ -111,18 +95,16 @@ You may read `..arm` as '`.` of the parent core of `arm`'. This amounts to just

11195

11296```

11397> ..inc:c

114−< 4.vgw

98+< 4.han

11599 { {our/@p now/@da eny/@uvJ}

116− $~

117− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

100+ <19.anu 24.tmo 6.ipz 38.ard 119.spd 241.plj 51.zox 93.pqh 74.dbd 1.qct $141>

118101 }

119102>

120103

121104> c

122−< 4.vgw

105+< 4.han

123106 { {our/@p now/@da eny/@uvJ}

124− $~

125− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

107+ <19.anu 24.tmo 6.ipz 38.ard 119.spd 241.plj 51.zox 93.pqh 74.dbd 1.qct $141>

126108 }

127109>

128110```

@@ -138,7 +120,7 @@ For an example of this, consider the `add` arm of the Hoon standard library. Th

138120<74.dbd 1.qct $141>

139121```

140122

141−Here you see a core with a battery of 31 arms, and whose payload is another core with one arm.

123+Here you see a core with a battery of 74 arms (!), and whose payload is another core with one arm.

142124

143125### Mutating a Gate

144126

@@ -151,7 +133,15 @@ Let's say you want to modify the default sample of the gate for `double`. We ca

151133

152134Given that `a x 2 = 0`, `a` must be `0`. (Remember that `a` is the face for the `double` sample, as defined in the core we bound to `c` above.)

153135

154−Let's say we want to modify the default sample to be `25`. There is only one problem: `double` isn't a gate! It's an arm that produces a gate, and every time it does so the default sample is `0`. If you want to mutate the gate produced by `double`, you'll first have to put a copy of that gate into the subject:

136+Let's say we want to mutate the `double` gate so that the default sample is `25`. There is only one problem: `double` isn't a gate!

137+

138+```

139+> double.c(a 25)

140+-tack.a

141+-find.a

142+```

143+

144+It's an arm that produces a gate, and `a` cannot be found in `double` until the gate is created. Furthermore, every time the gate is created, it has the default sample, `0`. If you want to mutate the gate produced by `double`, you'll first have to put a copy of that gate into the subject:

155145

156146```

157147> =double-copy double:c

@@ -174,10 +164,11 @@ Good. Let's call it with no argument and see if it returns double the value of

17416450

175165```

176166

177−It does indeed. Unbind `c` and `double-copy` as follows:

167+It does indeed. Unbind `c` and `double-copy`:

178168

179169```

180170> =c

171+

181172> =double-copy

182173```

183174

@@ -196,7 +187,7 @@ If you try to mutate the default sample of `add`, it won't work:

196187-find.a

197188```

198189

199−The reason it doesn't work is that `add` is an arm, not a gate. Hoon can't find an `a` to modify in a gate that doesn't exist yet!

190+As before with `double`, Hoon can't find an `a` to modify in a gate that doesn't exist yet.

200191

201192## Other Functions in the Hoon Standard Library

202193

@@ -207,7 +198,7 @@ Let's look once more at the parent core of the `add` arm in the Hoon standard li

207198<74.dbd 1.qct $141>

208199```

209200

210−The battery of this core contains 31 arms, each of which evaluates to a gate in the standard library. This 'library' is nothing more than a core containing useful basic functions that Hoon often makes available as part of the subject. You can see the Hoon code defining these arms near the beginning of [hoon.hoon](https://github.com/urbit/arvo/blob/master/sys/hoon.hoon), starting with [`++ add`](https://github.com/urbit/arvo/blob/master/sys/hoon.hoon#L21). (Yes, the Hoon standard library is written in Hoon.)

201+The battery of this core contains 74 arms, each of which evaluates to a gate in the standard library. This 'library' is nothing more than a core containing useful basic functions that Hoon often makes available as part of the subject. You can see the Hoon code defining these arms near the beginning of [hoon.hoon](https://github.com/urbit/arvo/blob/master/sys/hoon.hoon), starting with [`++ add`](https://github.com/urbit/arvo/blob/master/sys/hoon.hoon#L21). (Yes, the Hoon standard library is written in Hoon.)

211202

212203Here are some of the other gates that can be generated from this core in the Hoon standard library. It should be fairly obvious what they do:

213204

@@ -265,11 +256,11 @@ A brief review: A core is a cell of battery and payload: `[battery payload]`. T

265256New material: A *door* is a core with a sample. That is, a door is a core whose payload is a cell of sample and context: `[sample context]`.

266257

267258```

268− door

259+ Door

269260 / \

270−battery .

261+Battery .

271262 / \

272− sample context

263+ Sample Context

273264```

274265

275266It follows from this definition that a gate is a special case of a door. A gate is a door with exactly one arm, named `$`.

@@ -296,7 +287,7 @@ Before getting into what these arms do, let's cover how the `|_` rune works in g

296287

297288The `|_` rune for making a door works exactly like the `|%` rune for making a core, except it takes one additional subexpression.

298289

299−The first subexpression after the `|_` rune defines the door sample. (This is the subexpression the `|%` rune lacks.) Following that are a series of `++` runes, each of which defines an arm of the door. Finally, the expression is terminated with a `--` rune.

290+The first subexpression after the `|_` rune defines the door's sample. (This is the subexpression the `|%` rune lacks.) Following that are a series of `++` runes, each of which defines an arm of the door. Finally, the expression is terminated with a `--` rune.

300291

301292#### Back to the Example

302293

@@ -338,9 +329,11 @@ Having confirmed that `b` is `0`, let's mutate the `c` sample and then call its

338329%.n

339330```

340331

341−Doing the same mutation repeatedly can be tedious, so let's bind `c` to the modified version of the door:

332+Doing the same mutation repeatedly can be tedious, so let's bind `c` to the modified version of the door, where `b` is `7`:

342333

343334```

335+> =c c(b 7)

336+

344337> (plus:c 10)

34533817

346339

@@ -371,34 +364,32 @@ Readers with some mathematical background may notice that `~( )` expressions all

371364

372365```

373366> ~(plus c 7)

374−< 1.umt

367+< 1.gxk

375368 { a/@

376− < 3.uvn

369+ < 3.iba

377370 { b/@

378371 {our/@p now/@da eny/@uvJ}

379− $~

380− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

372+ < 19.anu

373+ 24.tmo

374+ 6.ipz

375+ 38.ard

376+ 119.spd

377+ 241.plj

378+ 51.zox

379+ 93.pqh

380+ 74.dbd

381+ 1.qct

382+ $141

383+ >

381384 }

382385 >

383386 }

384387>

385388

389+

386390> b:~(plus c 7)

3873917

388392

389−> ~(plus c 17)

390−< 1.umt

391− { a/@

392− < 3.uvn

393− { b/@

394− {our/@p now/@da eny/@uvJ}

395− $~

396− <16.igq 19.rrs 41.xjd 112.hmp 224.nab 54.tyv 119.wim 31.ohr 1.jmk $143>

397− }

398− >

399− }

400−>

401−

402393> b:~(plus c 17)

40339417

404395```

@@ -429,15 +420,15 @@ It turns out that the `rs` in `add:rs` is a Hoon standard library arm that produ

429420

430421```

431422> rs

432−<21?vij {r/?($n $u $d $z) <54.tyv 119.wim 31.ohr 1.jmk $143>}>

423+<21|fan {r/?($n $u $d $z) <51.zox 93.pqh 74.dbd 1.qct $141>}>

433424```

434425

435−The battery of this core, pretty-printed as `21?vij`, has 21 arms that define functions specifically for `@rs` atoms. One of these arms is named `add`; it's a different `add` from the standard one we've been using for vanilla atoms. So when you invoke `add:rs` instead of just `add` in a function call, (1) the `rs` door is produced, and then (2) the name search for `add` resolves to the special `add` arm in `rs`. This produces the gate for adding `@rs` atoms:

426+The battery of this core, pretty-printed as `21|fan`, has 21 arms that define functions specifically for `@rs` atoms. One of these arms is named `add`; it's a different `add` from the standard one we've been using for vanilla atoms. So when you invoke `add:rs` instead of just `add` in a function call, (1) the `rs` door is produced, and then (2) the name search for `add` resolves to the special `add` arm in `rs`. This produces the gate for adding `@rs` atoms:

436427

437428```

438429> add:rs

439−< 1.dfv

440− {{a/@rs b/@rs} <21.vij {r/?($n $u $d $z) <54.tyv 119.wim 31.ohr 1.jmk $143>}>}

430+< 1.hsu

431+ {{a/@rs b/@rs} <21.fan {r/?($n $u $d $z) <51.zox 93.pqh 74.dbd 1.qct $141>}>}

441432>

442433```

443434

@@ -456,8 +447,8 @@ Let's evaluate the `add` arm of `rs`, also modifying the door sample to `%u` for

456447

457448```

458449> ~(add rs %u)

459−< 1.dfv

460− {{a/@rs b/@rs} <21.vij {r/?($n $u $d $z) <54.tyv 119.wim 31.ohr 1.jmk $143>}>}

450+< 1.hsu

451+ {{a/@rs b/@rs} <21.fan {r/?($n $u $d $z) <51.zox 93.pqh 74.dbd 1.qct $141>}>}

461452>

462453```

463454