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

git.iko.soy/urbit.org

fixes to ch 1

356ec9ajoshuareagan8 years ago

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

78That'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.

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.

82### Payload

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

88### Subject Organization for Arm Computation

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.

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

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

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

2 navuptwo/'true'

3 next/'true'

4 sort/'5'

5− title/'1.5 Gates and Hoon Functions'

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

6 ==

7;>

9−# 1.5 Gates and Hoon Functions

9+# 1.5 Gates (Hoon Functions)

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+

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.

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.

13You'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:

21You'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:

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

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

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

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.

29```

37```

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

38+Gate: [$ [Sample Context]]

31```

39```

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−

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

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

37```

43```

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

47## Creating Your First Gate

53## Creating Your First Gate

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−

65Let'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':

55Let'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':

67```

57```

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

82### The `|=` Rune

72### The `|=` Rune

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).

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+

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.

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.

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

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

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

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.

94```

88```

95> inc

89> inc

96−< 1.viz

90+< 1.jgn

97 { a/@

91 { a/@

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

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

99− $~

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

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

101 }

94 }

102>

95>

103```

96```

104

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−

111### The `$` Arm

98### The `$` Arm

112

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.

114

101

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:

116

103

117```

104```

118> +2:inc

105> +2:inc

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

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

120```

107```

121

108

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.

123

110

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

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

125

112

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

138

125

139```

126```

140> inc

127> inc

141−< 1.viz

128+< 1.jgn

142 { a/@

129 { a/@

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

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

144− $~

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

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

146 }

132 }

147>

133>

148```

134```

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

173

159

174```

160```

175> +7:inc

161> +7:inc

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

162+[ [ our=~zod

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

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

178 eny

164 eny

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

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

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

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

181− \/ \/

167+ \/ \/

182 ]

168 ]

183− ~

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

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

185]

170]

186```

171```

187

172

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.

189

174

190### Exercise 1.5.1

175### Exercise 1.5.1

191

176

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

193

178

194## Gates Define Functions of the Sample

179## Gates Define Functions of the Sample

195

180

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.

197

182

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

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

199

184

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

254> (ten 35)

239> (ten 35)

25545

24045

256

241

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−

266> b.+7.ten

242> b.+7.ten

26710

24310

268```

244```

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

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

1:- :~ navhome/'/docs/'

2 navuptwo/'true'

3 sort/'6'

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

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

5 ==

6;>

8−# 1.6 Producing Gates with Core Arms

8+# 1.6 Multi-gate Cores and Doors

10It'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.

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

21> (inc 10)

2211

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−

44> =inc

24> =inc

45```

25```

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

54246

34246

55```

35```

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+

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

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

59```

41```

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

64276

46276

65```

47```

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

50+

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.

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

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.

71## A Gate-Building Core

55## A Gate-Building Core

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

101

102### The `..arm` Syntax

86### The `..arm` Syntax

103

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.

105

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?

107

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

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

109

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

111

112```

96```

113> ..inc:c

97> ..inc:c

114−< 4.vgw

98+< 4.han

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

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

116− $~

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

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

118 }

101 }

119>

102>

120

103

121> c

104> c

122−< 4.vgw

105+< 4.han

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

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

124− $~

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

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

126 }

108 }

127>

109>

128```

110```

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

138<74.dbd 1.qct $141>

120<74.dbd 1.qct $141>

139```

121```

140

122

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.

142

124

143### Mutating a Gate

125### Mutating a Gate

144

126

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

151

133

152Given 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.)

134Given 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.)

153

135

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+

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:

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:

155

145

156```

146```

157> =double-copy double:c

147> =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

17450

16450

175```

165```

176

166

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

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

178

168

179```

169```

180> =c

170> =c

171+

181> =double-copy

172> =double-copy

182```

173```

183

174

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

196-find.a

187-find.a

197```

188```

198

189

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.

200

191

201## Other Functions in the Hoon Standard Library

192## Other Functions in the Hoon Standard Library

202

193

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

207<74.dbd 1.qct $141>

198<74.dbd 1.qct $141>

208```

199```

209

200

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.)

211

202

212Here 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:

203Here 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:

213

204

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

265New 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]`.

256New 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]`.

266

257

267```

258```

268− door

259+ Door

269 / \

260 / \

270−battery .

261+Battery .

271 / \

262 / \

272− sample context

263+ Sample Context

273```

264```

274

265

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

266It 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

296

287

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

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

298

289

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.

300

291

301#### Back to the Example

292#### Back to the Example

302

293

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

338%.n

329%.n

339```

330```

340

331

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`:

342

333

343```

334```

335+> =c c(b 7)

336+

344> (plus:c 10)

337> (plus:c 10)

34517

33817

346

339

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

371

364

372```

365```

373> ~(plus c 7)

366> ~(plus c 7)

374−< 1.umt

367+< 1.gxk

375 { a/@

368 { a/@

376− < 3.uvn

369+ < 3.iba

377 { b/@

370 { b/@

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

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

379− $~

372+ < 19.anu

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

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+ >

381 }

384 }

382 >

385 >

383 }

386 }

384>

387>

385

388

389+

386> b:~(plus c 7)

390> b:~(plus c 7)

3877

3917

388

392

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−

402> b:~(plus c 17)

393> b:~(plus c 17)

40317

39417

404```

395```

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

429

420

430```

421```

431> rs

422> 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>}>

433```

424```

434

425

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:

436

427

437```

428```

438> add:rs

429> add:rs

439−< 1.dfv

430+< 1.hsu

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

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

441>

432>

442```

433```

443

434

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

456

447

457```

448```

458> ~(add rs %u)

449> ~(add rs %u)

459−< 1.dfv

450+< 1.hsu

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

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

461>

452>

462```

453```

463

454