on master help sign in
Merge pull request #144 from hoclun-rigsep/master

Rune documentation and various issues

commit8aec709667979663d019b60f15d6d23a53c36850 authorcgyarvin <curtis.yarvin@gmail.com> dateMon 13 Feb 2017, 10:36 (10 years ago) parentf26daae5a47f08
12 files changed+330−107
docs/about/glossary.md+97−89 docs/about/runtime.md+11−11 docs/hoon/syntax.md+6−4 docs/hoon/twig/bar-core/col-gasp.md+30 docs/hoon/twig/bar-core/ket-cork.md+54 docs/hoon/twig/bar-core/sig-port.md+38 docs/hoon/twig/bar-core/tar-gill.md+3−1 docs/hoon/twig/bar-core/wut-tray.md+42 docs/hoon/twig/cen-call/tar-bake.md+37 docs/hoon/twig/limb/limb.md+10 docs/hoon/twig/wut-test/ket-ifcl.md+1−1 docs/using/layout.md+1−1
docs/about/glossary.md+97−89
@@ -15,7 +15,7 @@ to create a new semantic level in which one can be absolutely precise."
1515
1616## Ships
1717
18−An Urbit `ship` is a cryptographic title on a `will` signed by private
18+An Urbit *ship* is a cryptographic title on a *will* signed by private
1919key, a human-memorable name, and a packet routing address. Ships are
2020classed by the number of bits in their address:
2121
@@ -27,7 +27,7 @@ classed by the number of bits in their address:
2727 2^64 moon planet device ~sigsam-nimbot-tasfyn-partyv
2828 2^128 comet ~ bot ~racmus-mollen-fallyt-linpex--watres-sibbur-modlux-rinmex
2929
30−Any ship can be called an `urbit`.
30+Any ship can be called an "urbit."
3131
3232> A summary [here](http://urbit.org/posts/address-space/).
3333
@@ -46,12 +46,12 @@ Shorter names are easier to remember, so they're more valuable. So
4646urbits are classified by the number of bits in their name. (A ship name
4747is just a scrambled base-256 representation of the number.)
4848
49−A 32-bit urbit (like `~firbyr-napbes`) is called a "planet." A 16-bit
50−urbit (like `~pollev)` is a "star." An 8-bit ship (like `~mun`) is a
51−"galaxy." A planet is an identity for an independent, adult human. Stars
49+A 32-bit urbit (like `~firbyr-napbes`) is called a *planet.* A 16-bit
50+urbit (like `~pollev)` is a *star.* An 8-bit ship (like `~mun`) is a
51+*galaxy.* A planet is an identity for an independent, adult human. Stars
5252and galaxies are network infrastructure.
5353
54−Each planet or star is launched by its "parent," the star or galaxy
54+Each planet or star is launched by its *parent,* the star or galaxy
5555whose number is its bottom half. So the planet `~firbyr-napbes`,
5656`0xdead.beef` or `3.735.928.559`, is the child of `~pollev`, `0xbeef` or
5757`48.879`, whose parent is `~mun`, `0xef`, `239`. The parent of `~mun`
@@ -61,14 +61,14 @@ and all galaxies is `~zod`, `0`.
6161
6262> Nock is a Turing-complete, non-lambda combinator interpreter.
6363
64−- `noun`: an `atom` or a `cell`
65−- `atom`: any natural number
66−- `cell`: any ordered pair of `noun`s
67−- `subject`: a `noun` - the data against which a `formula` is
64+- *noun*: an *atom* or a *cell*
65+- *atom*: any natural number
66+- *cell*: any ordered pair of nouns
67+- *subject*: a noun - the data against which a `formula` is
6868 evaluated
69−- `formula`: a `noun` - a function at the Nock level
70−- `product`: a `noun` - the result of evaluating a `formula` against a
71− `subject`
69+- *formula*: a noun - a function at the Nock level
70+- *product*: a noun - the result of evaluating a formula against a
71+ subject
7272
7373*See [Nock definition](../../nock/definition/).*
7474
@@ -77,49 +77,49 @@ and all galaxies is `~zod`, `0`.
7777> Hoon is a strict, higher-order typed functional language that compiles
7878> itself to Nock.
7979
80−###### `span`: an inferred type
80+###### span: an inferred type
8181
82−A `span` defines a set (finite or infinite) of `noun`s and ascribes some
83−semantics to it. There is no Hoon syntax for a `span`; it is always
84−produced as the inferred range of an expression (`twig`).
82+A *span* defines a set (finite or infinite) of nouns and ascribes some
83+semantics to it. There is no Hoon syntax for a span; it is always
84+produced as the inferred range of an expression (*twig*).
8585
8686*See [basic types](../../hoon/basic/#-type-span-and-mold).*
8787
88−###### `core`: a code-data `cell`
88+###### core: a code-data cell
8989
90−The code (`battery`) is the head, the data (`payload`) is the tail. All
90+The code (*battery*) is the head, the data (*payload*) is the tail. All
9191code-data structures in normal languages (functions, objects, modules,
92−etc) become `core`s in Hoon.
92+etc) become *core*s in Hoon.
9393
94−- `battery`: the code of a `core`, a tree of `arm`s
95−- `payload`: the data in a `core`
94+- *battery*: the code of a core, a tree of *arms*
95+- *payload*: the data in a core
9696
9797*See [basic types](../../hoon/basic)*.
9898
99−###### `arm`: a named, functionally-computed attribute of a `core`
99+###### arm: a named, functionally-computed attribute of a core
100100
101−The `twig` of each `arm` is compiled to a Nock formula, with the
101+The *twig* of each arm is compiled to a Nock formula, with the
102102enclosing `core` itself as the subject.
103103
104−There are two kinds of `arm`s: `dry` and `wet`. Most arms are dry.
104+There are two kinds of arms: *dry* and *wet*. Most arms are dry.
105105
106−- `dry`: normal, `++`, polymorphic by means of *variance*
106+- *dry*: normal, `++`, polymorphic by means of *variance*
107107
108−For a `dry` `arm`, we ask, is the new `payload` compatible with the old
109−`payload` (against which the `core` was compiled)?
108+For a dry arm, we ask, is the new payload compatible with the old
109+payload (against which the core was compiled)?
110110
111−- `wet`: unusual, `+-`, polymorphic by means of *genericity*
111+- *wet*: unusual, `+-`, polymorphic by means of *genericity*
112112
113−A `wet` `arm` uses the `twig` as a macro. We create a new type analysis
113+A wet arm uses the twig as a macro. We create a new type analysis
114114path, which works as if we expanded the callee with the caller's
115115context.
116116
117117*See [advanced types](/hoon/advanced)*.
118118
119−###### `metal`: a variance model
119+###### metal a variance model
120120
121−Every `core` has a `metal` which defines its *variance* model (ie, the
122−properties of the `span` of a compatible `core`). The default is `gold`
121+Every core has a *metal* which defines its variance model (ie, the
122+properties of the span of a compatible core). The default is `gold`
123123(invariant).
124124
125125- `gold`: *invariant*
@@ -129,87 +129,88 @@ properties of the `span` of a compatible `core`). The default is `gold`
129129
130130*See [advanced types](/hoon/advanced)*.
131131
132−###### `gate`: a function/lambda/closure
132+###### gate: a function/lambda/closure
133133
134−A `gate` is a `core` with one `arm`. To call a `gate` on an argument,
135−replace the `sample` (at tree address `6` in the `core`) with the
136−argument, and then compute the `arm`.
134+A *gate* is a core with one arm. To call a gate on an argument,
135+replace the sample (at [tree
136+address](../../hoon/twig/limb/limb/) `+6` in the core) with the
137+argument, and then compute the arm.
137138
138−The `payload` of a `gate` has a shape of `{sample context}`.
139+The payload of a gate has a shape of `{sample context}`.
139140
140−- `sample`: the argument tuple
141−- `context`: the subject in which the `gate` was defined
141+- *sample*: the argument tuple
142+- *context*: the subject in which the gate was defined
142143
143144*See [basic types](../../hoon/basic/#-core-p-span-q-map-term-span),
144145[`%-` or `:call`](../../hoon/twig/cen-call/hep-call/) (the `twig` for
145146calling a `gate`).*
146147
147−###### `mold`: a type constructor / validator
148+###### mold: a type constructor / validator
148149
149−A mold is an idempotent `gate` (function), accepting any `noun`, and
150−producing a range with a useful `span`.
150+A *mold* is an idempotent gate (function), accepting any noun, and
151+producing a range with a useful span.
151152
152−- `bunt`: the value a `mold` produces when normalizing its default
153+- *bunt*: the value a mold produces when normalizing its default
153154 sample
154−- `icon`: the `span` of the `mold`'s range
155+- *icon*: the span of the mold's range
155156
156−*See [`mold` `twig`s](/hoon/twig/buc-mold/).*
157+*See [mold twigs](/hoon/twig/buc-mold/).*
157158
158−###### `atom`
159+###### atom
159160
160−A Hoon `atom` span describes a Nock `atom`, with two additional pieces
161−of metadata: an `aura`, and an optional constant.
161+A Hoon *atom* span describes a Nock atom, with two additional pieces
162+of metadata: an *aura*, and an optional constant.
162163
163−An `atom` span is `warm` or `cold` based on whether the constant exists.
164+An atom span is *warm* or *cold* based on whether the constant exists.
164165
165−- `warm`: if the constant is `~` (null), any `atom` is in the `span`
166−- `cold`: if the constant is `[~ atom]`, its only legal value is
166+- *warm*: if the constant is `~` (null), any atom is in the span
167+- *cold*: if the constant is `[~ atom]`, its only legal value is
167168 `atom`.
168169
169170*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*
170171
171−###### `aura`: a soft `atom` type
172+###### *aura*: a soft atom type
172173
173−`aura` is a name for an atom type. It represents the structure of an
174−`atom` in a string beginning with `@`. An aura may represent units,
174+*aura* is a name for an atom type. It represents the structure of an
175+atom in a string beginning with `@`. An aura may represent units,
175176print format, or other semantics. Its constraints on the value of an
176177atom aren't enforced in any way.
177178
178−Two `aura`s are compatible if one is a prefix of the other. You can
179−change any `aura` into any other `aura` by casting through the empty
180−`aura`, `@`. The standard library has molds which alias many common
179+Two auras are compatible if one is a prefix of the other. You can
180+change any aura into any other aura by casting through the empty
181+aura, `@`. The standard library has molds which alias many common
181182auras.
182183
183184Some common auras and their aliases:
184185
185−- `term` (`@tas`): a symbol - an atomic ASCII string which obeys
186+- *term* (`@tas`): a symbol - an atomic ASCII string which obeys
186187 symbol rules: lowercase and digit only, infix hyphen ("kebab-case"),
187188 first character must be lowercase alphabetic.
188−- `cord` (`@t`): UTF-8 text, least-significant-byte first
189−- `char` (`@tD`): a character, a single unicode byte (for multi-byte
189+- *cord* (`@t`): UTF-8 text, least-significant-byte first
190+- *char* (`@tD`): a character, a single unicode byte (for multi-byte
190191 characters and codepoints, see `@c`)
191192
192193*See [basic types](../../hoon/basic/#-atom-p-term-q-unit-atom)*.
193194
194−###### `twig`: a Hoon expression
195+###### twig: a Hoon expression
195196
196−A `twig` is a Hoon expression. Specifically, `twig` is the mold for the
197+A *twig* is a Hoon expression. Specifically, twig is the mold for the
197198noun that a Hoon source expression compiles to. A twig is always a cell.
198199
199200A twig has one of two forms: `{twig twig}`, which produces the ordered
200201pair of the two twigs, or a cell `{stem bulb}`, where `stem` is an
201202atomic symbol.
202203
203−- `stem`: an atomic symbol (`@tas`) - the name of a `twig`.
204−- `bulb`: The `mold` of the `twig`'s contents.
204+- *stem*: an atomic symbol (`@tas`) - the name of a twig.
205+- *bulb*: The mold of the twig's contents.
205206
206−Most `twig`s have a *regular form*, beginning with a `sigil` which is
207−either a `keyword` or a `rune`. Some `twig`s also have a syntactic
207+Most twigs have a *regular form*, beginning with a *sigil* which is
208+either a *keyword* or a *rune*. Some twigs also have a syntactic
208209*irregular form*; a few have *only* an *irregular form*.
209210
210−- `sigil`: a `keyword` or `rune` used to begin a `twig`
211−- `keyword`: the value of a stem, prefixed with `:`.
212−- `rune`: a pair of ASCII symbols used to begin a `twig`.
211+- *sigil*: a *keyword* or *rune* used to begin a twig
212+- *keyword*: the value of a stem, prefixed with `:`.
213+- *rune*: a pair of ASCII symbols used to begin a twig.
213214
214215For example, the stem `%if` becomes the keyword
215216[`:if`](../../hoon/twig/wut-test/col-if/), with the rune `?:`. The first
@@ -222,47 +223,54 @@ easier.
222223
223224A regular twig has two syntactic forms, *tall* and *flat*:
224225
225−- `tall`: multiple lines, no parentheses, two or more spaces between
226+- *tall*: multiple lines, no parentheses, two or more spaces between
226227 tokens
227−- `flat`: one line, parentheses, one space between tokens
228+- *flat*: one line, parentheses, one space between tokens
228229
229−`tall` twigs can contain `flat` ones, but not vice versa. All irregular
230−forms are `flat`.
230+Tall twigs can contain flat ones, but not vice versa. All irregular
231+forms are flat.
231232
232−*See [`twig` concept](../../hoon/concepts/#-twig-expression),
233+*See [twig concept](../../hoon/concepts/#-twig-expression),
233234[expressions](../../hoon/twig/), and [syntax](../../hoon/syntax/)*.
234235
235−###### `limb`: attribute or variable reference
236+###### limb: attribute or variable reference
236237
237−To resolve a `limb` named "foo", the `subject` is searched depth-first,
238−head-first for either a `face` named "foo" or a `core` with an `arm` of
239−"foo". If a `face` is found, the result is a `leg`, if a `core` is
240−found, the result is the `product` of the `arm`.
238+To resolve a *limb* named "foo", the subject is searched depth-first,
239+head-first for either a face named "foo" or a core with an arm of
240+"foo". If a face is found, the result is a leg, if a core is
241+found, the result is the product of the arm.
241242
242−- `leg`: a subexpression, or subtree of the `subject`.
243−- `wing`: a list of `limb`s, searched from right to left (`a.b` means
243+- *leg*: a subexpression, or subtree of the subject.
244+- *wing*: a list of limbs, searched from right to left (`a.b` means
244245 `b` within `a`).
245246
246247*See [Limbs and wings](../../hoon/twig/limb)*
247248
248−###### `face`: a labeled subtree
249+###### slot: a tree addressing scheme
249250
250−Hoon has no scope or symbol-table; there is only the `subject`. To
251−"declare" a "variable" is to construct a new `subject`:
251+Every cell has a head and a tail, each of which may be either an atom or
252+a cell. Therefore every noun is a binary tree. `+1` or `.` resolves to
253+the whole cell (technically this would work against an atom as well).
254+The head of `+n` is `+2n`, the tail is `+(2n+1)`.
255+
256+###### face: a labeled subtree
257+
258+Hoon has no scope or symbol-table; there is only the subject. To
259+"declare" a "variable" is to construct a new subject:
252260`[name=value old-subject]`.
253261
254−A `face` is a `span` that wraps a name (`@tas`) around another `span`.
262+A *face* is a span that wraps a name (`@tas`) around another span.
255263
256264*See [advanced types](../../hoon/advanced/#-face-aliases-and-bridges)*.
257265
258−###### `nest`: type compatibility test
266+###### nest: type compatibility test
259267
260−`nest` is an internal function on two spans, which produces yes if the
268+*nest* is an internal function on two spans, which produces yes if the
261269set of nouns in the second span is provably a subset of the first.
262270
263271*See [advanced types](../../hoon/advanced/)*.
264272
265−###### `loobean`: a Hoon boolean
273+###### loobean: a Hoon boolean
266274
267275`0` (`%.y`) is *yes*, `1` (`%.n`) is *no*.
268276
docs/about/runtime.md+11−11
@@ -1510,27 +1510,27 @@ core? Slightly pseudocoded:
15101510
15111511 ++ arvo
15121512 |%
1513− ++ come |= [yen=@ ova=(list ovum) nyf=pone] :: 11
1514− ^- [(list ovum) _+>]
1513+ ++ come |/ {yen/@ ova/(list ovum) nyf/pone} :: 11
1514+ ^- {(list ovum) _+>}
15151515 !!
1516− ++ keep |= [now=@da hap=path] :: 4
1516+ ++ keep |/ {now/@da hap/path} :: 4
15171517 ^- (unit ,@da)
15181518 !!
1519− ++ load |= [yen=@ ova=(list ovum) nyf=pane] :: 86
1520− ^- [(list ovum) _+>]
1519+ ++ load |/ {yen/@ ova/(list ovum) nyf/pane} :: 86
1520+ ^- {(list ovum) _+>}
15211521 !!
1522− ++ peek |= [now=@da path] :: 87
1522+ ++ peek |/ {now/@da path} :: 87
15231523 ^- (unit)
15241524 !!
1525− ++ poke |= [now=@da ovo=ovum] :: 42
1526− ^- [(list ovum) _+>]
1525+ ++ poke |/ {now/@da ovo/ovum} :: 42
1526+ ^- {(list ovum) _+>}
15271527 !!
1528− ++ wish |= txt=@ta :: 20
1528+ ++ wish |/ txt/@ta :: 20
15291529 ^- *
15301530 !!
15311531 --
1532− ++ card ,[p=@tas q=*] :: typeless card
1533− ++ ovum ,[p=wire q=card] :: Arvo event
1532+ ++ card {p/@tas q/*} :: typeless card
1533+ ++ ovum {p/wire q/card} :: Arvo event
15341534 ++ wire path :: event cause
15351535
15361536This is the Arvo ABI in a very real sense. Arvo is a core with
docs/hoon/syntax.md+6−4
@@ -289,10 +289,12 @@ of a core. A conventional example:
289289
290290```
291291|%
292−++ foo
293− p
294−++ bar
295− q
292+++ dry-arm-foo
293+ %p
294+++ dry-arm-bar
295+ %q
296++- wet-arm-baz
297+ %r
296298--
297299```
298300
docs/hoon/twig/bar-core/col-gasp.mdnew file+30
@@ -0,0 +1,30 @@
1+---
2+navhome: /docs
3+sort: 8
4+
5+---
6+
7+# `:gasp |: "barcol"`
8+
9+`{$gasp p/seed q/seed}`: form a gate with burnt sample.
10+
11+## Expands to
12+
13+```
14+:pin :burn(p)
15+:trap(q)
16+```
17+
18+```
19+=> ^~ p
20+ |. q
21+```
22+
23+## Discussion
24+
25+Note that `p` is a seed, not a moss; `:gasp` doesn't bunt your sample as
26+`:gate` does.
27+
28+## Syntax
29+
30+Regular: *2-fixed*.
docs/hoon/twig/bar-core/ket-cork.mdnew file+54
@@ -0,0 +1,54 @@
1+---
2+navhome: /docs
3+sort: 7
4+
5+---
6+
7+# `:cork |^ "barket"`
8+
9+`{$cork p/twig q/(map term foot)}`: form a core with battery and
10+anonymous arm `$` and kick it.
11+
12+## Expands to
13+
14+```
15+:per :core
16+ ++ $ p
17+ q
18+ --
19+$
20+```
21+
22+```
23+=> |%
24+ ++ $ p
25+ q
26+ --
27+$
28+```
29+
30+## Syntax
31+
32+Regular: *1-fixed*, then *battery*.
33+
34+## Examples
35+
36+A trivial cork:
37+
38+```
39+~zod:dojo> :cork
40+ (add n g)
41+ ++ n 42
42+ ++ g 58
43+ --
44+```
45+
46+```
47+~zod:dojo> |^
48+ (add n g)
49+ ++ n 42
50+ ++ g 58
51+ --
52+100
53+```
54+
docs/hoon/twig/bar-core/sig-port.mdnew file+38
@@ -0,0 +1,38 @@
1+---
2+navhome: /docs
3+sort: 10
4+
5+---
6+
7+# `:port |~ "barsig"`
8+
9+`{$port p/moss q/seed}`: form an iron gate.
10+
11+## Expands to
12+
13+```
14+:iron :gate(p q)
15+```
16+
17+```
18+^| |=(p q)
19+```
20+
21+## Syntax
22+
23+Regular: *2-fixed*.
24+
25+## Discussion
26+
27+See [this discussion of core variance models](../../../advanced)
28+
29+## Examples
30+
31+```
32+~zod:dojo> :per ~ :like(:port(a/@ *@) :gate(a/* *@))
33+```
34+
35+```
36+~zod:dojo> => ~ ^+(|~(a/@ *@) |=(a/* *@))
37+<1|usl {a/@ $~}>
38+```
docs/hoon/twig/bar-core/tar-gill.md+3−1
@@ -20,7 +20,9 @@ core with sample.
2020
2121```
2222=| p
23−|% +- $ q
23+|%
24++- $
25+ q
2426--
2527```
2628
docs/hoon/twig/bar-core/wut-tray.mdnew file+42
@@ -0,0 +1,42 @@
1+---
2+navhome: /docs
3+sort: 9
4+
5+---
6+
7+# `:tray |? "barwut"`
8+
9+`{$tray p/seed}`: form a lead trap.
10+
11+## Expands to
12+
13+```
14+:lead :trap p
15+```
16+
17+```
18+^? |. p
19+```
20+
21+## Syntax
22+
23+Regular: *1-fixed*.
24+
25+## Discussion
26+
27+See this [discussion of the core variance model](../../../advanced).
28+
29+## Examples
30+
31+```
32+~zod:dojo> :per ~ :like :tray(%a) :trap(%a)
33+<1?pqz $~>
34+~zod:dojo> :per ~ :like :tray(%a) :trap(%b)
35+nest-fail
36+```
37+```
38+~zod:dojo> => ~ ^+ |?(%a) |.(%a)
39+<1?pqz $~>
40+~zod:dojo> => ~ ^+ |?(%a) |.(%b)
41+nest-fail
42+```
docs/hoon/twig/cen-call/tar-bake.mdnew file+37
@@ -0,0 +1,37 @@
1+---
2+navhome: /docs
3+sort: 8
4+---
5+
6+# `:bake %* "centar"`
7+
8+`{$bake p/wing q/twig r/(list (pair wing seed))}`: make
9+with arbitrary twig.
10+
11+## Expands to
12+
13+```
14+:pin q
15+:make p
16+r
17+```
18+
19+```
20+=+ q
21+=% p
22+r
23+```
24+
25+## Syntax
26+
27+Regular: *2-fixed*, then *jogging*.
28+
29+## Examples
30+
31+```
32+~zod:dojo> %*($ add a 2, b 3)
33+5
34+~zod:dojo> =foo [a=1 b=2 c=3 d=4]
35+~zod:dojo> %*(+ foo c %hello, d %world)
36+[b=2 c=%hello d=%world e=5]
37+```
docs/hoon/twig/limb/limb.md+10
@@ -21,10 +21,20 @@ Irregular: `+15` is slot `15`, `[%& 15]`.
2121
2222Irregular: `.` is slot `1`, the whole subject.
2323
24+Irregular: `&4` is slot `30`, the 4th element of a tuple
25+with at least 5 elements.
26+
27+Irregular: `|4` is slot `31`, the elements that follow `&4`.
28+
2429Irregular: `foobar` is `[%| 0 %foobar]`.
2530
2631Irregular: `^^^foobar` is `[%| 3 %foobar]`.
2732
33+Irregular: `+<-` is "take the tail, then take the head of
34+that, then the head of that." `+` and `>` mean "tail" while
35+`-` and `<` mean "head." This limb syntax starts on `+` or `-`
36+and alternates for readability.
37+
2838### Traverse
2939
3040The search traverse takes a name `q` and a *skip count* `p`.
docs/hoon/twig/wut-test/ket-ifcl.md+1−1
@@ -6,7 +6,7 @@ sort: 5
66# `:ifcl ?^ "wutket"`
77
88`{$ifcl p/wing q/seed r/seed}`: branch on whether a wing
9−of the subject is null.
9+of the subject is a cell.
1010
1111## Expands to
1212
docs/using/layout.md+1−1
@@ -91,7 +91,7 @@ This is where marks live. Marks are data type definitions used by `%ford`. A m
9191
9292These are web renderers. A renderer handles web requests of a particular type.
9393
94−Default web requets in urbit are handled as a `.urb`, which is caught by the `urb.hoon` renderer. This wraps the request in our default `css` and `js` and adds some routing magic for certain paths.
94+Default web requests in urbit are handled as a `.urb`, which is caught by the `urb.hoon` renderer. This wraps the request in our default `css` and `js` and adds some routing magic for certain paths.
9595
9696## `sur/`
9797