git.iko.soy/urbit.org
on 01ac191 help sign in
urbit.org/docs/programming/hoon/twig/limb.md
105 lines 3.4 kB history raw
1---
2sort: 2
3next: true
4---
6# Limbs and wings
8One feature Hoon lacks: a context that isn't a first-class value.
9Hoon has no concept of scope, environment, etc. A twig has one
10data source, the *subject*, a noun like any other.
12In most languages "variable" and "attribute" are different
13things. They are both symbols, but a variable is in "the
14environment" and a attribute is on "an object." In Hoon, "the
15environment" is "an object" -- the subject.
17`$limb` and `$wing` are two basic twig stems that extract
18information from the subject. A `limb` is an attribute; a `wing`
19is an attribute path, ie, a list of limbs.
21## Twigs
23The limb and wing system, as molds:
25```
26++ limb
27 $% {$& p/@ud}
28 {$| p/@ud q/@tas}
29 ==
30++ wing (list limb)
31++ twig
32 $% {$limb p/limb}
33 {$wing p/wing}
34 ==
35```
37The basic reference twigs are `$limb` and `$wing`. `$limb`
38is a single reference step into the subject. `$wing` is a path
39of reference steps.
41## Limbs and wings
43A `limb` is either *geometric*, `{$& p/@ud}`, or *symbolic*,
44`{$| p/@ud q/@tas}`.
46The result of compiling a limb is either an *arm* or a *leg*. A
47leg is a subtree of the subject. An arm is a computed attribute
48on a core which is a subtree of the subject. (See `$core` in
49[span](../span).)
51A geometric limb always compiles to a leg. A symbolic limb may
52compile to an arm or a leg, depending on the subject.
54### Geometric limb, `{$& p/@ud}`
56`p` is a Nock tree address in the subject. If you don't know
57Nock, tree addresses are a way of designating a subtree of a noun
58with an atom. The root is `1`, the left child of any node `n` is
59`(mul 2 n)`, the right child is `(add 1 (mul 2 n))`.
61### Symbolic limb
63A symbolic limb has a name `q` and a *skip count* `p`.
65To resolve the limb to arm or leg, we search the subject
66headfirst and depth-first. If we descend to a `$face` span whose
67label matches the limb symbol, the descent address is a leg; the
68span is the span beneath the label. But if the `$face` label
69differs, the search skips this subtree.
71If we descend into a `$core` span in which the limb symbol is an
72arm, we produce that arm. If the limb symbol is not bound, we
73descend into the payload (data) of the core.
75If the skip count `p` is nonzero, we pretend our first `p`
76matches are actually mismatches. This lets the programmer "look
77through" an overriding label. No label anywhere is inaccessible.
79### Wing
81A `wing` is a symbolic reference path, `(list limb)`. Taking a
82wing is not quite the same as composing each of these limbs,
83though; the product of a wing is still either an arm or a leg.
85This is trivial if each step in the wing is a leg. If an
86intermediate step in a wing compiles to an arm, this arm is
87rewritten; it becomes a leg to the arm's core.
89### Syntax
91All limb references are irregular.
93A geometric limb `x` is `+x`. `.` means `+1`.
95A symbolic limb `foo` is `foo`; the symbol is naked. To set a
96nonzero skip count, use a unary `^` prefix; thus `^foo` skips one
97match, and `^^^foo` skips three.
99The empty name `$` is the label whose value is 0. By convention,
100`$` is always an arm, usually on a one-armed core (such as a
101function or loop). To take `$` on a noun is to *kick* it.
103A wing is written outside-in with `.` as a separator. So
104`foo.bar.baz` is "foo, in bar, in baz." Yes, this is the
105opposite of what you're used to.