29332ab · urbit.org · git.iko.soy

git.iko.soy/urbit.org

Merge remote-tracking branches 'joemfb/find-fand', 'ray/patch-1', 'asgardiator/master' and 'torchhound/master' into HEAD

commit29332ab7cd889ab3a98cc17aa4f0ae48ab4ee2b3 authorPhilip C Monk <philip.monk@tlon.io> dateWed 13 Jul 2016, 16:52 (10 years ago) parent307dfde 12c8b78 649fcd1 b67a378

4 files changed+13−18

compare with master

unifiedsplit

docs/arvo/basic.md+4−9 docs/hoon/advanced.md+7−7 docs/hoon/examples.md+1−1 docs/hoon/twig.md+1−1

docs/arvo/basic.md+4−9

@@ -2,20 +2,15 @@

22navhome: /docs

33sort: 1

44next: true

5−title: Hoon refresher / crash course

5+title: Basic Hoon

66---

88Basic Hoon

99==========

1010

11−This recapitulates material you've already learned in

12−[Hoon](/docs/hoon/). It will be a very abrupt tutorial if you don't know

13−Hoon already, but it may be enough in and of itself. If you don't find

14−it obvious at first glance, try working up from Hoon.

15−

1611Our goal is to get you programming interesting and useful things as soon

1712as possible. To get there, we have to quickly cover some of the

18−fundamentals of hoon. To do this, we'll walk through two simple

13+fundamentals of [Hoon](/docs/hoon/). To do this, we'll walk through two simple

1914programs: the first [Project Euler](https://projecteuler.net/) problem

2015and [fizzbuzz](https://en.wikipedia.org/wiki/Fizz_buzz).

2116

@@ -38,8 +33,8 @@ Make sure you've mounted your `%home` desk:

3833Then, copy the example into it

3934

4035```

41−$ cp -r {urbit-examples}/gall/*/ {your-pier}/home/

42−$ cp -r {urbit-examples}/dojo/*/ {your-pier}/home/

36+$ cp -r {urbit-examples}/gall/*/*/ {your-pier}/home/

37+$ cp -r {urbit-examples}/dojo/*/*/ {your-pier}/home/

4338```

4439

4540Run an example to ensure it worked:

docs/hoon/advanced.md+7−7

@@ -72,12 +72,12 @@ polymorphism relies on genericity.

7272### Dry arms

7373

7474For a dry arm, we apply the Liskov substitution principle: we

75−ask, "can we use any `p` as if it was a `q.q`"? This is the same

75+ask, "can we use any `p` as if it was a `q.q`?" This is the same

7676test as in `:cast` or any type comparison (`nest`). Intuitively,

77−we ask: is the new payload compatible with the old payload?

77+we ask: "is the new payload compatible with the old payload?"

7878

7979For a core `a`, if `p.a` fits in `q.q.a`, we can use arms on the

80−core. The product of an dry arm whose twig is `b` is always

80+core. The product of a dry arm whose twig is `b` is always

8181defined as `{$hold a(p q.q.a, p.q %gold) b}`.

8282

8383In other words, the subject of the arm computation is the

@@ -89,7 +89,7 @@ call in most languages.

8989

9090Dry polymorphism works by substituting cores. Typically, the

9191the programmer uses one core as an interface definition, then

92−replace it with another core which does something useful.

92+replaces it with another core which does something useful.

9393

9494For core `b` to nest within core `a`, the batteries of `a` and

9595`b` must have the same tree shape, and the product of each `b`

@@ -108,7 +108,7 @@ is gold; a gold core can be cast or converted to any metal, and

108108any metal can be cast or converted to lead.

109109

110110A gold core `a` has a read-write payload; another core `b` that

111−nests within it (ie, can be substituted for it) must be a gold

111+nests within it (i.e., can be substituted for it) must be a gold

112112core whose payload is mutually compatible (`+3.a` nests in `+3.b`,

113113`+3.b` nests in `+3.a`). Hence, *invariant*.

114114

@@ -128,8 +128,8 @@ nests within `+6.a`. Hence, *covariant*.

128128

129129### Wet arms

130130

131−For a wet arm, we ask: suppose this core was actually compiled

132−using `p` instead of `q.q`? Would the Nock formula we generated

131+For a wet arm, we ask: "suppose this core was actually compiled

132+using `p` instead of `q.q`?" Would the Nock formula we generated

133133for `q.q` actually work for a `p` payload?

134134

135135A wet arm with twig `b` in core `a` produces the span `{$hold a

docs/hoon/examples.md+1−1

@@ -313,7 +313,7 @@ Line `13` defines the `spot` mold, a 2D coordinate.

313313 == :: 16

314314```

315315

316−Lines `14` to `16` define the `fact` mold, a game event (ie,

316+Lines `14` to `16` define the `fact` mold, a game event (i.e.,

317317output action), as a book (tagged union). There are two forms of

318318`fact`: `[%tie ~]` (reporting a tie), and `[%win cord]`

319319(reporting that `'X'` or `'O'` won a game.

docs/hoon/twig.md+1−1

@@ -28,7 +28,7 @@ Most stems are implemented as internal macros, however.

2828The bulb is usually a tuple, sometimes a list or map. An element

2929of this structure is a *subexpression* or just *leg*.

3030

31−Usually a subexpression is itself a `twig`; sometimes it's an

31+Usually a subexpression is itself a `twig`; sometimes it's a

3232`@tas` (symbol) or a `wing` (reference path).

3333

3434## Moldy moss; woody seed