git.iko.soy/urbit.org
on 8c634ff help sign in
urbit.org/docs/programming/nock.md
167 lines 5.6 kB history raw
1---
2sort: 5
3next: true
4title: Interpreter
5---
7# Interpreter: `nock`
9The Nock VM is a Turing-complete function that maps a cell
10`{subject formula}` to a noun `product`, where `subject` is the
11data, `formula` is the code, and `product` is the result.
13To program in Hoon, this is all you need to know about Nock.
14It's probably at least worth skimming the definition, though.
16(Also, the Hoon programmer should know that (a) tail call
17elimination in Nock is straightforward; and (b) tail calls in
18Hoon always become tail calls in Nock.)
20## Rules
22Nock is a combinator interpreter defined by the spec below.
24This pseudocode (any system of axioms is properly defined in
25pseudocode) is a system of problem reduction rules. Variables
26match any noun; the first rule from the top matches.
28A problem that reduces to itself is an infinite loop, hence a
29crash ("bottom" in formal logic). Obviously a real interpreter
30can detect this crash and produce an out-of-band value instead.
32```
33?[a b] 0
34?a 1
35+[a b] +[a b]
36+a 1 + a
37=[a a] 0
38=[a b] 1
39=a =a
41/[1 a] a
42/[2 a b] a
43/[3 a b] b
44/[(a + a) b] /[2 /[a b]]
45/[(a + a + 1) b] /[3 /[a b]]
46/a /a
48*[a [b c] d] [*[a b c] *[a d]]
50*[a 0 b] /[b a]
51*[a 1 b] b
52*[a 2 b c] *[*[a b] *[a c]]
53*[a 3 b] ?*[a b]
54*[a 4 b] +*[a b]
55*[a 5 b] =*[a b]
57*[a 6 b c d] *[a 2 [0 1] 2 [1 c d] [1 0]
58 2 [1 2 3] [1 0] 4 4 b]
59*[a 7 b c] *[a 2 b 1 c]
60*[a 8 b c] *[a 7 [[7 [0 1] b] 0 1] c]
61*[a 9 b c] *[a 7 c 2 [0 1] 0 b]
62*[a 10 [b c] d] *[a 8 c 7 [0 3] d]
63*[a 10 b c] *[a c]
65*a *a
66```
68## Operators
70The pseudocode notation defines five prefix operators: `?`, `+`,
71`=`, `/`, and `*`.
73`?[x]` produces `0` if `x` is a cell, `1` if an atom.
75`+[x]` produces the atom `x` plus `1`.
77`=[x y]` produces `0` if `x` and `y` are the same noun, `1`
78otherwise.
80`/` (`slot`) is a tree addressing operator. The root of the tree
81is `1`; the left child of any node `n` is `2n`; the right child
82is `2n+1`. `/[x y]` is the subtree of `y` at address `x`.
84(For instance, `/[1 [531 25 99]]` is `[531 25 99]`; `/[2 [531 25
8599]]` is `531`; `/[3 [531 25 99]]` is `[25 99]`; `/[6 [531 25
8699]]` is `25`; `/[12 [531 25 99]]` crashes.)
88`*[x y]` is the Nock interpreter function. `x` is the subject,
89`y` is the formula.
91An invalid use of any operator (eg, incrementing a cell) crashes.
92This is specified as an infinite loop, but it's not actually an
93infinite loop.
95## Instructions
97A valid formula is always a cell. If the head of the formula is a
98cell, Nock treats both head and tail as formulas, resolves each
99against the subject, and produces the cell of their products. In
100other words, the Lisp program `(cons x y)` becomes the Nock
101formula `[x y]`.
103If the head of the formula is an atom, it's an instruction from
104`0` to `10`.
106A formula `[0 b]` produces the noun at tree address `b`
107in the subject.
109A formula `[1 b]` produces the constant noun `b`.
111A formula `[2 b c]` treats `b` and `c` is formulas, resolves each
112against the subject, then computes Nock again with the product of
113`b` as the subject, `c` as the formula.
115In formulas `[3 b]`, `[4 b]`, and `[5 b]`, `b` is another
116formula, whose product against the subject becomes the input to
117an axiomatic operator. `3` is `?`, `4` is `+`, `5` is `=`.
119Instructions `6` through `10` are macros; deleting them
120from Nock would decrease compactness, but not expressiveness.
122`[6 b c d]` is *if* `b`, *then* `c`, *else* `d`. Each of `b`,
123`c`, `d` is a formula against the subject. Remember that `0` is
124true and `1` is false.
126`[7 b c]` composes the formulas `b` and `c`.
128`[8 b c]` produces the product of formula `c`, against
129a subject whose head is the product of formula `b` with the
130original subject, and whose tail is the original subject. (Think
131of `8` as a ``variable declaration'' or ``stack push.'')
133`[9 b c]` computes the product of formula `c` with the current
134subject; from that product `d` it extracts a formula `e` at tree
135address `b`, then computes `*[d e]`. (`9` is designed to fit
136Hoon; `d` is a `core` (object), `e` points to an arm (method).)
138`[10 b c]` is a *hint* semantically equivalent to the formula
139`c`. If `b` is an atom, it's a *static hint*, which is just
140discarded. If `b` is a cell, it's a *dynamic* hint; the head of
141`b` is discarded, and the tail of `b` is executed as a formula
142against the current subject; the product of this is discarded.
144A practical interpreter can do anything with discarded data, so
145long as the result it computes complies with the semantics of
146Nock. For example, the simplest use of hints is the ordinary
147"debug printf." It is erroneous for an interpreter to skip
148computing dynamic hints; they might crash.
150## Implementation
152The reader might wonder how an interpreter whose only arithmetic
153operation is increment can ever be practical.
155The short answer is that a Nock interpreter doesn't have to use
156the algorithm above. It just has to get the *same result* as the
157algorithm above.
159The algorithm for decrementing an atom is to count up to it, an
160O(n) operation. But if the interpreter knows it's running a
161decrement formula, it can use the CPU to decrement directly.
163Detecting any Nock formula whose semantics match some function,
164like decrement, is a hard problem. But in practice there is only
165one decrement we run -- the decrement in the kernel library.
166Declaring this formula (with a hint, instruction `10` above)
167and recognizing it is not hard.