@@ -227,12 +227,6 @@ if `q:ankh` is null), then this produces null.
227#### `$ankh`, filesystem node
227#### `$ankh`, filesystem node
230− ++ ankh :: fs node (new)
231− $: p=cash :: recursive hash
232− q=(unit ,[p=cash q=*]) :: file
233− r=(map ,@ta ankh) :: folders
236+$ ankh :: expanded node
230+$ ankh :: expanded node
238 $: fil=(unit [p=lobe q=cage]) :: file
232 $: fil=(unit [p=lobe q=cage]) :: file
@@ -255,17 +249,24 @@ are, recursively, the nodes themselves.
255### `$arch`, shallow filesystem node
249### `$arch`, shallow filesystem node
258− ++ arch ,[p=@uvI q=(unit ,@uvI) r=(map ,@ta ,~)] :: fundamental node
259+$ arch (axil @uvI)
252+$ arch (axil @uvI)
255+ [fil=(unit item) dir=(map @ta ~)]
262−This is analogous to `++ankh:clay` except that the we have neither our
258+An `arch` is a lightweight version of an `ankh` that only contains the hash
263−contents nor the ankhs of our children. The other fields are exactly the
259+of the associated file and a `map` of child directories, but not the children of
264−same, so `p` is a hash of the associated ankh, `u.q`, if it exists, is a
260+those directories.
265−hash of the contents of this node, and the keys of `r` are the names of
261+
266−our children. `r` is a map to null rather than a set so that the
262+The child directories are given by a `map` to null rather than a `set` so that the
267−ordering of the map will be equivalent to that of `r:ankh`, allowing
263+ordering of the `map` will be the same as it is for an `axal`, allowing
268−efficient conversion.
264+efficient conversion for when the heavier node is needed.
268+ [fil=(unit item) dir=(map @ta $)]
270#### `++case:clay`, specifying a commit
271#### `++case:clay`, specifying a commit