@@ -176,7 +176,7 @@ Of course, the fragment retains the type it had when we built it.
176176## Labeled surfaces
177177
178178We can obviously get anything we want out of the subject by tree
179−geometry. But it's not really how we'd like to program. We'd
179+geometry. But that's not really how we'd like to program. We'd
180180much rather *label* subtrees with convenient, memorable symbols.
181181
182182For example, suppose our tree looked like:
@@ -220,7 +220,7 @@ table here -- just a tree search.
220220
221221An expression like the label `x` or the axis `+2`, which
222222designates a fragment or feature of the subject, is called a
223−*limb*. Limbs can be connected with a `.`, making a *wing*.
223+*limb*. A list of limbs connected with `.`, is a *wing*.
224224
225225To remind you that you're not in Kansas anymore, the syntax for a
226226wing, like `q.y` above, means means "q inside y." In a classic
@@ -233,7 +233,7 @@ that is, attribute `q` within object `y`. In Hoon, `q.y` means
233233Once again, Hoon has no symbol tables. When we put a surface
234234on a noun, the surface label is part of that noun's type. It's
235235not part of the cell or other structure that contains the noun.
236−For example:
236+This will take a little getting used to:
237237
238238```
239239> ? x:a
@@ -249,8 +249,8 @@ x=42
24924942
250250```
251251
252−When we take fragment 2 of the labeled subject the *surface
253−comes with it *. `+2` is not `42` but rather `x=42`. We can
252+When we take fragment 2 of the labeled subject, the *surface
253+comes with it*. `+2` is not `42` but rather `x=42`. We can
254254take the surface off with `x.+2`.
255255
256256## The search algorithm
@@ -323,18 +323,22 @@ classical language. But where is Hoon's equivalent of objects:
323323values which bind code to data?
324324
325325The Hoon equivalent of an object is a *core*. As usual in Hoon,
326−the resemblance isn't exact. A core has a set of computed
326+the resemblance is inexact. A core has a set of computed
327327attributes, or *arms*. Each arm is an expression whose subject
328328is the core. There is no argument, so an arm is not a method.
329329
330330Physically, a core is always a cell `[battery payload]`, where
331331the *payload* is any noun, and the *battery* is a tree of
332332formulas in Nock (Hoon's functional assembly language) that
333−implements the arms.
333+implements the arms. (A battery is like a C++ vtable, sort of.)
334334
335−As you'd expect with a computed attribute, an expression which
336−uses a label can't know whether the subject will resolve it to a
337−surface fragment (a *leg*) or to an arm.
335+## The search algorithm
336+
337+As you'd expect with a computed attribute, there is only one
338+namespace and one search algorithm. We just extend the algorithm
339+described above. And an expression which uses a label can't know
340+whether the subject will resolve it to a surface fragment (a
341+*leg*) or to an arm.
338342
339343If we're searching a core and the label matches one of the core's
340344arms, we compute the arm against the core. If the label is not
@@ -357,10 +361,55 @@ from "two or more spaces."
35736142
358362
359363> =b :per a :core ++ foo x ++ bar [q.y foo] --
364+```
365+
366+We're seeing some Hoon regular forms for the first time. `x:a`
367+turns out to be an irregular relative of the regular `:per` form.
368+
369+We'll get more into syntax in a later Urbyte. If some of these
370+examples seem syntactically a little funky, this isn't usually
371+way we'd do them in "real life." We don't normally write cores
372+on a single command line. In a file this would be:
373+
374+```
375+ :per a
376+ :core
377+ ++ foo x
378+ ++ bar [q.y foo]
379+ --
380+```
381+
382+which is much more readable, at least once you get used to it.
383+Let's look at the core itself:
360384
385+```
361386> b
362387<2.spy {x/@ud y/{p/$foo q/@rs r/@dr} x/@ux}>
363388
389+> ? +2:b
390+ *
391+[[0 6] [0 58] 9 4 0 1]
392+
393+> ? +3:b
394+ {x/@ud y/{p/$foo q/@rs r/@dr} x/@ux}
395+[x=42 y=[p=%foo q=.6.28 r=~m45] x=0xdead.beef]
396+```
397+
398+When we print `b`, or any core, we see that typed noun printing
399+can't be an invertible function in Hoon.
400+
401+We actually can read the battery (with `+2:b` above), but it's
402+just Nock code, not typed data. `<2.spy>` tells us the battery
403+has two arms and hashes to the three-letter code `spy`.
404+
405+When printing a full core, we don't even print the payload data,
406+just its type. But our `+3:b` confirms the `[battery payload]`
407+structure of the core. Remember, `+2` is the head and `+3` is
408+the tail.
409+
410+Finally, let's use this thing:
411+
412+```
364413> ? foo:b
365414 @ud
36641542
@@ -372,27 +421,9 @@ from "two or more spaces."
372421? x:b
373422 @ud
37442342
375−
376−> ? +2:b
377− *
378−[[0 6] [0 58] 9 4 0 1]
379424```
380425
381−We're seeing some Hoon regular forms for the first time. `x:a`
382−turns out to be an irregular relative of the regular `:per` form.
383−
384−(We'll get more into syntax in a later Urbyte. If some of these
385−examples seem syntactically a little funky, this isn't usually
386−way we'd do them in "real life." We don't normally write cores
387−on one line in the dojo, for instance.)
388−
389−And when we print `b`, or any core, we see that typed noun
390−printing can't be an invertible function in Hoon.
391−
392−We actually can read the battery (with `+2:b` above), but it's
393−just Nock code, not typed data. We don't even print the payload
394−data, though we print the payload type. The `<2.spy>` just shows
395−a core with two arms, for which `spy` is a hash code.
426+Seems legit.
396427
397428## The dojo subject
398429
@@ -415,14 +446,14 @@ directly at the real dojo subject:
415446
416447We see a bunch of surfaces: our custom `a` and `b`; standard
417448surfaces for identity, date, and entropy; and a ginormous core
418−stack with almost a thousand total arms.
449+stack with *over eight hundred* total arms.
419450
420451To be exact, the syntax `<283.xzp 42.ajz 407.xtr 110.xht 1.ztu
421−$151>` denotes a system of six cores, each of whose payload is
452+$151>` denotes a stack of six cores, each of whose payload is
422453another core, until the innermost payload `%151` (the Hoon
423−version). This stack is our standard library, from which comes
424−`add` and other fine functions. (We don't know how to define a
425−Hoon function yet, but we're getting close.)
454+version number). This stack is our standard library, from which
455+comes `add` and other fine functions. (We don't know how to
456+write a Hoon function yet, but we're getting way closer.)
426457
427458Let's clean up our subject, just to be hygienic:
428459
@@ -458,7 +489,7 @@ $
458489As always, these questions are optional and only for fun.
459490
460491What's the best way to construct a core which acts as a function?
461−How do you call the function?
492+What do you do to call the function?
462493
463494Why don't any other languages use subject-oriented programming?
464495Which languages are most similar to it?