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