on master help sign in
Merge pull request #990 from urbit/type-code-fix
a3ea637poprox
reference/hoon-expressions/advanced.md+23−20
@@ -18,27 +18,29 @@ large functions. Don't worry about them for a little while.
18 $@ $? %noun
18 $@ $? %noun
19 %void
19 %void
20 ==
20 ==
21− $% [$atom p=term q=(unit @)]
21+ $% [%atom p=term q=(unit @)]
22− [$cell p=type q=type]
22+ [%cell p=type q=type]
23− [$core p=type q=coil]
23+ [%core p=type q=coil]
24− [$face p=$@(term tune) q=type]
24+ [%face p=$@(term tune) q=type]
25− [$fork p=(set type)]
25+ [%fork p=(set type)]
26− [$hint p=(pair type note) q=type]
26+ [%hint p=(pair type note) q=type]
27− [$hold p=type q=hoon]
27+ [%hold p=type q=hoon]
28 ==
28 ==
29::
29::
30−+$ coil $: p=[p=(unit term) q=poly r=vair]
30++$ coil $: p=garb :: name, wet=dry, vary
31− q=type
31+ q=type :: context
32− r=[p=seminoun q=(map term tome)]
32+ r=(pair seminoun (map term tome)) :: chapters
33+ == ::
33::
34::
35++$ garb (trel (unit term) poly vair) :: core
34+$ poly ?(%wet %dry)
36+$ poly ?(%wet %dry)
35−+$ vair ?($gold $iron $lead $zinc)
37++$ vair ?(%gold %iron %lead %zinc)
36+$ tome (pair what (map term hoon))
38+$ tome (pair what (map term hoon))
37−+$ tune
39++$ tune :: complex
38− $~ [~ ~]
40+ $~ [~ ~] ::
39− $: p=(map term (unit hoon))
41+ $: p=(map term (unit hoon)) :: aliases
40− q=(list hoon)
42+ q=(list hoon) :: bridges
41− ==
43+ == ::
42```
44```
43
45
44If you compare this to the basic `type`, you'll see that we've
46If you compare this to the basic `type`, you'll see that we've
@@ -66,8 +68,9 @@ the payload the core was compiled with is `q.q`.
66
68
67In the Bertrand Meyer tradition of type theory, there are two
69In the Bertrand Meyer tradition of type theory, there are two
68forms of polymorphism: variance and genericity. In Hoon this
70forms of polymorphism: variance and genericity. In Hoon this
69−choice is per core, hence the `poly` label in `coil`: it can be either `%wet` or `%dry`. Dry polymorphism relies on variance; wet
71+choice is per core, hence the `poly` label in `p.q`: it can be either `%wet`
72+or `%dry`. Dry polymorphism relies on variance; wet polymorphism relies on
70−polymorphism relies on genericity.
73+genericity.
71
74
72### Dry arms
75### Dry arms
73
76
@@ -188,13 +191,13 @@ of secret superpowers for hacking the namespace. Remember that
188Hoon doesn't have anything like a symbol table; to resolve a
191Hoon doesn't have anything like a symbol table; to resolve a
189limb, we just search the type depth-first.
192limb, we just search the type depth-first.
190
193
191−If a name is in the `p.p` map, it's an alias. (An alias is defined using the
194+If a name is in the `p.p` `map`, it's an alias. (An alias is defined using the
192`=*` rune.) The map contains a `(unit hoon)`; if the unit is full, the name
195`=*` rune.) The map contains a `(unit hoon)`; if the unit is full, the name
193resolves to that hoon (compiled against the `q` type). If the unit is empty,
196resolves to that hoon (compiled against the `q` type). If the unit is empty,
194the name is blocked / skipped (see [limb](@/docs/reference/hoon-expressions/limb/limb.md) for what
197the name is blocked / skipped (see [limb](@/docs/reference/hoon-expressions/limb/limb.md) for what
195this means).
198this means).
196
199
197−If a name is in the `q.p` map, it's a bridge. (A bridge is defined using the
200+If a name is the `q.p` `term`, it's a bridge. (A bridge is defined using the
198`=,` rune.) When we search for a name, we also compile the bridge, and check
201`=,` rune.) When we search for a name, we also compile the bridge, and check
199if the name resolves against the bridge product. If so, we use it.
202if the name resolves against the bridge product. If so, we use it.
200
203