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

29332abPhilip C Monk10 years ago

docs/arvo/basic.md+4−9

compare with master

unifiedsplit

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

2navhome: /docs

3sort: 1

4next: true

5−title: Hoon refresher / crash course

5+title: Basic Hoon

6---

8Basic Hoon

9==========

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−

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

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

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

12as 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

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

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

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

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

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

38Then, copy the example into it

33Then, copy the example into it

40```

35```

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

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

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

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

43```

38```

45Run an example to ensure it worked:

40Run an example to ensure it worked:

docs/hoon/advanced.md+7−7

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

72### Dry arms

74For 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

76test 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?"

79For 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

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

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

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

90Dry polymorphism works by substituting cores. Typically, the

91the 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.

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

95`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

108any metal can be cast or converted to lead.

109

110A 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

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

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

114

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

128

129### Wet arms

130

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

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

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

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

134

135A 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.

313 == :: 16

314```

315

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.,

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

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

319(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.

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

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

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

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

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

34## Moldy moss; woody seed