Add part 3 & 4

post-2.md

@@ -1,8 +1,13 @@
 ---
 date: ~2016.6.23
-title: Learning Hoon - Part 2: cores
+author: Matthew Steedman
+title: Learning Hoon - Part 2: Cores
 type: post
-navhome: /blog
+navhome: /learning-hoon
+navdpad: false
+navmode: navbar
+sort: 3
+next: true
 ---
 
 In the previous post we explored gates a bit which are just "dry one-armed cores with sample". In Hoon, a `core` is a bit like an object in other languages. Its members/attributes are called `arms`. So now let's explore `cores` a bit.
@@ -18,7 +23,7 @@ When we created a `gate` earlier, what we really created was a `core` with one `
 --
 ```
 
-The first rune `|%` creates a new core, then `++` creates a new `arm` on that `core` named 'bar' with the value of "Hello!". Finally the `--` tells hoon we're done adding `arms`. If we were to assign this `core` to a variable in the dojo like: `=foo |%  ++  bar  "hello"  --` we could then access its arm like this: `bar.foo`. Notice how the attribute accessor syntax is backwards compared to most other languages. If this `core` was written in javascript it might look something like this:
+The first rune `|%` creates a new core, then `++` creates a new `arm` on that `core` named 'bar' with the value of "Hello!". Finally the `--` tells hoon we're done adding `arms`. Because `|%` is one of those rare stems that don't know how many children to expect, we need to end the twig with `--` when we're done. If we were to assign this `core` to a variable in the dojo like: `=foo |%  ++  bar  "hello"  --` we could then access its arm like this: `bar.foo`. Notice how the attribute accessor syntax is backwards compared to most other languages. If this `core` was written in javascript it might look something like this:
 
 ```
 { bar: "Hello!" }
@@ -38,7 +43,7 @@ So now that we know, roughly, what cores are, here's what our gate from [part 1]
 --
 ```
 
-Let's go through this step by step. The first rune, `=|` essentially declares an uninitialized variable (`a/@`) to be used in the following twig (the subject, our `core`).
+Let's go through this step by step. The first rune, `=|` essentially declares an uninitialized variable (`a/@`) to be used in the following twig (the [subject](/post-3), our `core`).
 
 > ###### :new =| , "tisbar"
 > `{$new p/moss q/seed}`: combine a defaulted mold with the subject.
@@ -73,7 +78,7 @@ The truth is, gates are a type of core, yes, but more generally they are a type
 --
 ```
 
-I should note that you can use `|_` to make doors explicitly in the same way we use `|=` to make gates explicitly without having to construct the core manually.
+I should note that you can use `|_` to make doors explicitly in the same way we use `|=` to make gates explicitly without having to construct the core manually. Notice how `|_`, `|=` and `|%` all begin with `|`? That's because they all belong to the [Core family of runes](http://urbit.org/docs/hoon/twig/bar-core/).
 
 ```
 |_  a/@
@@ -128,7 +133,7 @@ The interesting part here is `$(a (add a 1))`, which calls the same empty-named
 > ###### :make %= "centis"
 > `{$make p/wing q/(list (pair wing seed))}`: take a wing with changes.
 
-Here, `p/wing` is referring to some "attribute", in this case `$`, an arm on a core. The following twig, `q/(list (pair wing seed))` is a list of `wing seed` pairs. We already know that a wing is like an attribute, and a seed could be anything. Those pairs represent the attribute we want to change, and what we want to change it to. Going back to our example, `%=($ a (add a 1))`, we have `$` as our `p/wing` and `a (add a 1)` as our `q/(list (pair wing seed))`. So within the context of `$`, we're changing `a` to be `(add a 1)`.
+Here, `p/wing` is referring to some "attribute", in this case `$`, an arm on a core. The following twig, `q/(list (pair wing seed))` is a list of `wing seed` pairs. We already know that a wing is like an attribute, and a seed could be anything. Those pairs represent the attribute we want to change, and what we want to change it to. Going back to our example, `%=($ a (add a 1))`, we have `$` as our `wing` and `a (add a 1)` as our `(list (pair wing seed))`. So within the context of `$`, we're changing `a` to be `(add a 1)`.
 
 But why can't we just call `($ (add a 1))` like a normal gate? Because `$` *isn't* a gate. Remember, a gate is a *core* and `$` is an arm on that core (the only arm, in fact). Further, `%=` isn't just limited to arms on a core. It works for other `limbs` (attributes) as well. Take the following example:
 

post-3.md

@@ -0,0 +1,109 @@
+---
+date: ~2016.6.23
+author: Matthew Steedman
+title: Learning Hoon - Part 3: Subject
+type: post
+navhome: /learning-hoon
+navdpad: false
+navmode: navbar
+sort: 4
+next: true
+---
+
+In part 2 we talked about cores, how they relate to gates, and how their attributes work. Part of that post dealt with declaring variables to be used within a core, as well as attributes (`arms`) of a core, and how they are related. In part 3 we'll explore the concept of variables, attributes, and scope within Hoon.
+
+## Declaring a variable
+
+In other languages, such as javascript, we can declare a variable  like this:
+
+```
+var a;
+```
+
+Once we've declared it, we're free to use it in the rest of the program, the *environment*:
+
+```
+var a;
+{ foo: a }
+```
+
+In hoon, we can do something similar using `=|` to declare an "uninitialized" variable (actually it's a defaulted variable):
+
+```
+=|  a/@
+|%  ++  foo  a --
+```
+
+But what happens when we try to use `=|` by itself?
+
+```
+dojo> =|  a/@
+dojo<
+```
+
+Hmm, the dojo is expecting more stuff. Let's look at the docs for `=|`:
+
+> ###### :new =| , "tisbar"
+> `{$new p/moss q/seed}`: combine a defaulted mold with the subject.
+
+As you can see, `=|` expects two children: `p/moss`, which is the variable to declare, and `q/seed`, the context, or *subject* to declare it in. 
+
+> One feature Hoon lacks: a context that isn't a first-class value. Hoon has no concept of scope, environment, etc. A twig has one data source, the subject, a noun like any other.
+>
+> In most languages "variable" and "attribute" are different things. They are both symbols, but a variable is in "the environment" and a attribute is on "an object." In Hoon, "the environment" is "an object" -- the subject.
+
+We can actually prove that "variables" in hoon are attributes by using the attribute accessor syntax we saw earlier:
+
+```
+dojo> =bizz [c=1 d=2]
+dojo> c.bizz
+1
+dojo> =foo =|  a/@  |%  ++  bar  a --
+dojo> bar.foo
+0
+dojo> a.foo
+0
+```
+
+And if we want to declare two variables in a row? The context created by the second variable declaration becomes the subject for the first, as illustrated here:
+
+<img src="https://dl.dropboxusercontent.com/s/k1qnge5s0e99j63/tisbar.png" alt="tisbar" width="600"/>
+
+In Hoon, we call the code executed the "formula" and its context the "subject". here is a more fleshed out example from the [arvo  tutorial](http://urbit.org/docs/arvo/subject/):
+
+```
+::::::::::::::::::::::::::::::
+=<  (sum [1.000 2.000])     :: formula
+::::::::::::::::::::::::::::::
+|%                          ::
+++  three                   ::
+  |=  a/@                   ::
+  =|  b/@                   ::
+  |-  ^-  @u                ::
+  ?:  (lth a b)             ::
+    0                       ::
+  (add b $(b (add 3 b)))    ::
+                            ::
+++  five                    ::
+  |=  a/@                   ::  subject
+  =|  b/@                   ::
+  |-  ^-  @                 ::
+  ?:  (lte a b)             ::
+    0                       ::
+  ?:  =((mod b 3) 0)        ::
+    $(b (add b 5))          ::
+  (add b $(b (add b 5)))    ::
+                            ::
+++  sum                     ::
+  |=  {a/@u b/@u}           ::
+  (add (five a) (three b))  ::
+--                          ::
+::::::::::::::::::::::::::::::
+```
+
+In this example we're using `=<`, which is, obviously, different from `=|`, but the concept is similar (hence the common prefix `=`).
+
+> ###### :rap =< "tisgal"
+> `{$rap p/seed q/seed}`: compose two twigs, inverted.
+
+Essentially `=<` executes the first twig, (the formula, `p/seed`) in the *context* of the second twig (the subject, `q/seed`).

_draft_molds → post-4.md

@@ -1,8 +1,14 @@
 ---
 date: ~2016.6.23
-title: Learning Hoon - Part 2: molds
+author: Matthew Steedman
+title: Learning Hoon - Part 4: Molds
 type: post
-navhome: /blog
+navhome: /learning-hoon
+navdpad: false
+navmode: navbar
+sort: 5
+hide: true
+next: true
 ---
 
 In the previous post we explored gates and different ways of calling and making them. One thing we noticed is that making a gate requires things called `molds` which we don't know much about yet. So let's explore them.
@@ -58,3 +64,9 @@ dojo> (@ux 1)
 
 
 A lot of the documentation for different `stems` shows the bulb's legs as either `moss` or `seed`. What are they? Well to keep things brief, a `moss` is a twig that produces a `mold` and a `seed` is a twig that produces anything else. You can read more about `moss` and `seed` [here](http://urbit.org/docs/hoon/twig/).
+
+
+---
+
+those are functions whose range of possible outputs
+are used to define a span at compile time