git.iko.soy/urbit.org
on master help sign in
minor changes to runes in reference
48f43e0joshuareagan
docs/reference/rune.udon+1−1
compare with master
unifiedsplit
@@ -6,7 +6,7 @@
6
6
7# Runes
7# Runes
8
8
9−### _...and how to form Hoon expressions_
9+### Forming Expressions of Hoon
10
10
11;div(class "book")
11;div(class "book")
12
12
docs/reference/rune/constants/cold.udon+5−4
@@ -17,13 +17,13 @@ A cold (fixed) atom `q` with aura `p`.
17
17
18### Syntax
18### Syntax
19
19
20−Irregular: any warm atom [(`%sand`)](../warm/) form, prefixed with `%`.
20+Irregular: any [warm atom](../warm/) form, prefixed with `%`.
21
21
22Irregular: e.g., `%hi`. Character constraints: `a-z`
22Irregular: e.g., `%hi`. Character constraints: `a-z`
23lowercase to start, `a-z` or `0-9` thereafter, with infix
23lowercase to start, `a-z` or `0-9` thereafter, with infix
24hyphens (`hep`), "kebab-case."
24hyphens (`hep`), "kebab-case."
25
25
26−Irregular: `~`, `@n`, null (`0`).
26+Irregular: `~`.
27
27
28### Examples
28### Examples
29
29
@@ -35,6 +35,7 @@ We can see the contrast with warm atoms by using the compiler parser function, `
35
35
36> (ream '\'hi\'')
36> (ream '\'hi\'')
37[%sand p=%t q=26.984]
37[%sand p=%t q=26.984]
38−```
39
38
40−Cold atoms all have the aura `@tas`. (Hence the `p=%tas` in the parsed result of `%12`.)
39+> (ream '%12')
40+[%rock p=%ud q=12]
41+```
docs/reference/rune/constants/text.udon+5−2
@@ -1,11 +1,11 @@
1:- :~ navhome/'/docs/'
1:- :~ navhome/'/docs/'
2 navuptwo/'true'
2 navuptwo/'true'
3 sort/'3'
3 sort/'3'
4− title/'Text /w Interpolation'
4+ title/'Strings'
5 ==
5 ==
6;>
6;>
7
7
8−# Text with Interpolation
8+# Strings with Interpolation
9
9
10`[%knit p=(list (each @t hoon))]`: text string with interpolation.
10`[%knit p=(list (each @t hoon))]`: text string with interpolation.
11
11
@@ -25,6 +25,9 @@ Irregular: `"abc{(weld "lmnop" "xyz")}defg"`.
25
25
26> "abc{(weld "lmnop" "xyz")}defg"
26> "abc{(weld "lmnop" "xyz")}defg"
27"abclmnopxyzdefg"
27"abclmnopxyzdefg"
28+
29+> (ream '"abcdefg"')
30+[%knit p=~[97 98 99 100 101 102 103]]
28```
31```
29
32
30### Examples
33### Examples
docs/reference/rune/dot/ket.udon+4−4
@@ -6,7 +6,7 @@
6
6
7# `.^ "dotket"`
7# `.^ "dotket"`
8
8
9−`[%dtkt p=spec q=hoon]`: load from the Arvo namespace with Nock `11`.
9+`[%dtkt p=spec q=hoon]`: load from the Arvo namespace with a fake Nock instruction: 'Nock `12`''.
10
10
11## Produces
11## Produces
12
12
@@ -14,8 +14,8 @@ The noun `q`, cast to the type `p`.
14
14
15## Discussion
15## Discussion
16
16
17−Nock has no `11` instruction, of course. But the virtual Nock
17+Nock has no `12` instruction! But the virtual Nock
18−used to run userspace code does. Nock `11` loads from a
18+used to run userspace code does. Nock `12` loads from a
19typed immutable namespace defined by its virtual context.
19typed immutable namespace defined by its virtual context.
20
20
21Ordinarily a Hoon expression has access to no information but whatever can be found in the subject. The one exception is with the `.^` rune. It essentially allows you to request information from one of the Arvo vanes (modules).
21Ordinarily a Hoon expression has access to no information but whatever can be found in the subject. The one exception is with the `.^` rune. It essentially allows you to request information from one of the Arvo vanes (modules).
@@ -26,7 +26,7 @@ In principle `.^` takes two subexpressions, but in practice `q` is often given i
26
26
27## Examples
27## Examples
28
28
29−In the dojo we can ask Clay for a listing of the files at our current path, `%`:
29+In the dojo we can ask Clay -- the Arvo filesystem -- for a listing of the files at our current path, `%`:
30
30
31```
31```
32> .^(arch %cy %)
32> .^(arch %cy %)
docs/reference/rune/dot/lus.udon+1−1
@@ -7,7 +7,7 @@
7
7
8# `.+ "dotlus"`
8# `.+ "dotlus"`
9
9
10−`[%dtls p=atom]`: increment an atom with Nock `4`.
10+`[%dtls p=hoon]`: increment an atom with Nock `4`.
11
11
12## Produces
12## Produces
13
13
docs/reference/rune/dot/tar.udon+4−3
@@ -19,11 +19,12 @@ Regular: *2-fixed*.
19
19
20## Discussion
20## Discussion
21
21
22+`.*(p q)` is used to run Nock formula `p` on the subject `q` from within Hoon.
23+
22Keep in mind that `p` and `q` can be arbitrary Hoon expressions, as long as they evaluate to the appropriate nouns for Nock evaluation.
24Keep in mind that `p` and `q` can be arbitrary Hoon expressions, as long as they evaluate to the appropriate nouns for Nock evaluation.
23
25
24−Note that `.*` ("dottar") can be used to bypass the type system,
26+Note also that `.*` ("dottar") can be used to bypass the type system. It's
25−though its product contains no type information. It's
26−perfectly possible to use Hoon as a typeless language.
27+therefore possible to use Hoon as a typeless language.
27
28
28## Examples
29## Examples
29
30
docs/reference/rune/dot/tis.udon+1−1
@@ -23,7 +23,7 @@ Irregular: `=(a b)` is `.=(a b)`.
23
23
24The test for equality includes a type check. Either the type of `p` must nest under the type of `q`, or _vice versa_. Otherwise the result is a crash.
24The test for equality includes a type check. Either the type of `p` must nest under the type of `q`, or _vice versa_. Otherwise the result is a crash.
25
25
26−Like Nock equality, `.=` ("dottis") tests if two nouns are the same,
26+Like Nock equality, `.=` ("dottis") tests whether two nouns are the same,
27ignoring invisible pointer structure. Because in a conventional
27ignoring invisible pointer structure. Because in a conventional
28noun implementation each noun has a lazy short hash, comparisons
28noun implementation each noun has a lazy short hash, comparisons
29are fast unless the hash needs to be computed, or we are comparing
29are fast unless the hash needs to be computed, or we are comparing
docs/reference/rune/limb/limb.udon+4−4
@@ -5,15 +5,15 @@
5 ==
5 ==
6;>
6;>
7
7
8−# Limbs
8+# Limb Expressions
9
9
10−Attribute of subject.
10+A limb is an attribute of subject.
11
11
12### Produces
12### Produces
13
13
14−If a limb resolves to a leg of the subject, the leg is produced. If a limb resolves to an arm by way of an arm name, then the arm is evaluated with its parent core as the subject and the result of that evaluation is produced.
14+There are two kinds of limbs: arms and legs. An *arm* is a computation of some core. A *leg* is a piece of data in the subject.
15
15
16−An arm is a Nock formula in the battery of a core. A leg is any other piece of data in the subject.
16+If a limb expression resolves to a leg, the leg is produced. If a limb expression resolves to an arm -- in particular, by way of an arm name -- then the arm is computed with its parent core as the subject. The result of that computation is produced.
17
17
18### Syntax
18### Syntax
19
19
docs/reference/rune/limb/wing.udon+7−3
@@ -5,13 +5,15 @@
5 ==
5 ==
6;>
6;>
7
7
8−# Wings
8+# Wing Expressions
9
9
10+`[%wing p=(list limb)]`
11+
10−`[%wing p=(list limb)]`; a limb search path into the subject.
12+A wing is a limb search path into the subject.
11
13
12### Produces
14### Produces
13
15
14−A wing is a list of limbs (including a trivial list of one limb). The limbs are resolved to values in the subject in succession, and the result of the last limb resolution is the value produced by the wing.
16+A wing is a list of limbs (including a trivial list of one limb). The limbs are resolved in succession. The result of the last limb resolution is the value produced by the wing expression.
15
17
16### Syntax
18### Syntax
17
19
@@ -36,8 +38,10 @@ is the same limb as `+`, `..b` is the same wing as `+1.foo`.
36
38
37```
39```
38~zod:dojo> =a [fod=3 bat=[baz=1 moo=2]]
40~zod:dojo> =a [fod=3 bat=[baz=1 moo=2]]
41+
39~zod:dojo> bat.a
42~zod:dojo> bat.a
40[baz=1 moo=2]
43[baz=1 moo=2]
44+
41~zod:dojo> moo.bat.a
45~zod:dojo> moo.bat.a
422
462
43```
47```
docs/reference/rune/sig/zap.udon+1−1
@@ -1,7 +1,7 @@
1:- :~ navhome/'/docs/'
1:- :~ navhome/'/docs/'
2 next/'true'
2 next/'true'
3 sort/'6'
3 sort/'6'
4− title/'~? "sigzap"'
4+ title/'~! "sigzap"'
5 ==
5 ==
6;>
6;>
7
7