@@ -189,14 +189,22 @@ It is good practice to include a cast in all gates, even wet gates. But in many
189189
190190As is the case with dry arms, there is a type-check associated with each wet arm. Or, rather, there are potentially many checks for each wet arm, one for each wing in the code that resolves to a wet arm. The product type of that arm is inferred at each call site, using the argument value type given at that site. If the type inference doesn't go through -- e.g., if there is a cast that doesn't succeed relative to the call site argument value -- then the compile will crash with a `nest-fail`. Otherwise the type check goes through with the inferred type of the wet arm at that call site. So the product type of a wet gate can differ from one call site to another, as we saw with `switch` above.
191191
192−### Parametric Polymorphism and `+*` Arms
192+### Parametric Polymorphism and `|$`
193193
194−We may use the `+*` rune to define an arm that produced a more complex type from one or more simpler types. This rune provides a way of making use of **parametric polymorphism** in Hoon.
194+We first encountered `|$` in the lesson on
195+[molds](@/docs/tutorials/hoon/molds.md) as a wet gate that is a mold builder rune which takes in a
196+list of molds and produces a new mold. Here we take another look at this rune as
197+an implementation of **parametric polymorphism** in Hoon.
195198
196−For example, we have `list`s, `tree`s, and `set`s in Hoon, which are each defined in `hoon.hoon` with `+*` arms. (Take a moment to see for yourself.) Each `+*` arm is followed by an argument definition, inside brackets `[ ]`. After that subexpression comes another that defines a type, relative to the input value. For example, here is the definition of `list` from `hoon.hoon`:
199+For example, we have `list`s, `tree`s, and `set`s in Hoon, which are each
200+defined in `hoon.hoon` as wet gate mold builders. Take a moment to see for
201+yourself. Each `++` arm is followed by `|$` and a list of labels for input
202+types inside brackets `[ ]`. After that subexpression comes another that
203+defines a type that is parametrically polymorphic with respect to the input values. For example, here is the definition of `list` from `hoon.hoon`:
197204
198205```hoon
199−+* list [item]
206+++ list
207+ |$ [item]
200208 :: null-terminated list
201209 ::
202210 :: mold generator: produces a mold of a null-terminated list of the
@@ -205,9 +213,9 @@ For example, we have `list`s, `tree`s, and `set`s in Hoon, which are each define
205213 $@(~ [i=item t=(list item)])
206214```
207215
208−The `+*` rune is especially useful for defining [containers](https://en.wikipedia.org/wiki/Container_%28abstract_data_type%29) of various kinds. Indeed, `list`s, `tree`s, and `set`s are all examples of containers. You can have a `(list @)`, a `(list ^)`, a `(list *)`, and so on. Or a `(tree @)`, a `(tree ^)`, a `(tree *)`, etc. And the same for `set`.
216+The `|$` rune is especially useful for defining [containers](https://en.wikipedia.org/wiki/Container_%28abstract_data_type%29) of various kinds. Indeed, `list`s, `tree`s, and `set`s are all examples of containers. You can have a `(list @)`, a `(list ^)`, a `(list *)`, and so on. Or a `(tree @)`, a `(tree ^)`, a `(tree *)`, etc. And the same for `set`.
209217
210−One nice thing about containers defined by `+*` is that they nest in the expected way. Intuitively a `(list @)` should nest under `(list *)`, because `@` nests under `*`. And so it does:
218+One nice thing about containers defined by `|$` is that they nest in the expected way. Intuitively a `(list @)` should nest under `(list *)`, because `@` nests under `*`. And so it does:
211219
212220```
213221> =a `(list @)`~[11 22 33]