@@ -34,7 +34,7 @@ OK /sys/hoon/set/test-set-wyt
3434```
3535Here, we ran a generator called `+test` with a path argument `/sys/hoon/set`. The output tells us that all tests ran successfully. Running this generator automatically appends `/tests/` to the front of the path entered, so lets look at the beginning of `/tests/sys/hoon/set.hoon` to see what the `+test` generator took as an input:
3636
37−```
37+```hoon
3838:: Tests for +in (set logic)
3939::
4040/+ *test
@@ -46,7 +46,7 @@ Here, we ran a generator called `+test` with a path argument `/sys/hoon/set`. Th
4646We note that the first line that isn't a comment is `/+ *test`, which from [the previous lesson](../ford.md) you know means that we are importing the shared library `lib/test.hoon`. This is followed by a core which will contain arms that perform our tests, which we will see an example of shortly.
4747
4848In `lib/test.hoon`, we find a core with a few gates: `expect-eq`, `expect-fail`, and `category`. The source for `expect-eq` is:
49−```
49+```hoon
5050++ expect-eq
5151 |= [expected=vase actual=vase]
5252 ^- tang
@@ -75,7 +75,7 @@ This is the most frequently used gate in testing, so we may conclude that any te
7575## Testing the functionality of set intersection
7676
7777Here's one of the testing arms in the set testing core:
78−```
78+```hoon
7979++ test-set-int ^- tang
8080 =/ s-nul=(set @) *(set @)
8181 =/ s-asc=(set @) (sy (gulf 1 7))
@@ -109,7 +109,7 @@ Here's one of the testing arms in the set testing core:
109109 ==
110110```
111111This arm is used to test whether the set intersection functionality works as expected. Let's walk through it line by line.
112−```
112+```hoon
113113++ test-set-int ^- tang
114114 =/ s-nul=(set @) *(set @)
115115 =/ s-asc=(set @) (sy (gulf 1 7))
@@ -118,11 +118,11 @@ This arm is used to test whether the set intersection functionality works as exp
118118 =/ s-dup (sy ~[1 1 4 1 3 5 9 4])
119119```
120120We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds several sets to the subject which will be utilized in our tests.
121−```
121+```hoon
122122;: weld
123123```
124124`;: weld` calls `weld`, which is typically a binary function, as an n-ary function. This will allow us to concatenate all of `tang`s that are to be generated into a single `tang`.
125−```
125+```hoon
126126 :: Checks with empty set
127127 ::
128128 %+ expect-eq
@@ -130,7 +130,7 @@ We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds s
130130 !> (~(int in s-nul) s-asc)
131131```
132132`%+` is used to call a gate with a cell sample. `expect-eq` is the gate, `!> ~` is the head of the sample, and `!> (~(int in s-nul) s-asc)` is the tail of the sample. `!>` is a rune used to wrap a noun in its type - in other words, it produces a `vase`. We've seen this rune before when we learned about the type spear `-:!>`. Thus, what this block of code is doing is checking whether the expected `vase` that is the product of `!> ~` is equal to the `vase` that is the product of `!> (~(int in s-nul) s-asc)`. `s-nul` is simply the empty set, and here we are taking the intersection of the empty set with `s-asc`, a non-empty set. This ought to produce the empty set of course, and so when this block of code runs, we compare the expected result `!> ~` (which is something we determined by hand) with the actual result `!> (~(int in s-nul) s-asc)`.
133−```
133+```hoon
134134 %+ expect-eq
135135 !> ~
136136 !> (~(int in s-asc) s-nul)
@@ -138,7 +138,7 @@ We see that this arm returns a `tang`, i.e. a pretty-printed message, and adds s
138138This is another test to check if intersection works with the empty set, but we have swapped where `s-asc` and `s-nul` are. We do not know a priori whether this ordering matters (and of course it shouldn't), which is why it is important to perform both tests.
139139
140140
141−```
141+```hoon
142142 :: Checks with all elements different
143143 ::
144144 %+ expect-eq
@@ -147,7 +147,7 @@ This is another test to check if intersection works with the empty set, but we h
147147```
148148Now we are checking if intersection works correctly when two non-empty sets share no common elements. We expect the intersection to be empty, so our expected `vase` is `!> ~`, and we then compare it with what the set library produces when it takes the intersection of `s-dos` and `s-asc`.
149149
150−```
150+```hoon
151151 :: Checks success (total intersection)
152152 ::
153153 %+ expect-eq
@@ -156,7 +156,7 @@ Now we are checking if intersection works correctly when two non-empty sets shar
156156```
157157`s-asc` and `s-des` both ought to be the set containing the integers 1 through 7, but `s-asc` was generated with the list `~[1,2,3,4,5,6,7]` while `s-des` was generated with the list `~[7,6,5,4,3,2,1]`. Sets have no ordering, so they ought to be the same. Thus, when we take their intersection, we should get the same set back. So, our expected `vase` is `!> s-asc` and our actual `vase` is `!> (~(int in s-asc) s-des)`.
158158
159−```
159+```hoon
160160 :: Checks success (partial intersection)
161161 ::
162162 %+ expect-eq