tweak zipper
[lambda.git] / zipper.mdwn
index bcb2d8b..1db9e9a 100644 (file)
@@ -153,7 +153,7 @@ Or, if we only had labels on the leafs of our tree:
           siblings = [node 20; *; node 80]
        }, * filled by node 50
 
-We're understanding the `20` here in `node 20` to just be a metalanguage marker to help us theorists keep track of which node we're referring to. We're supposing the tree structure itself doesn't associate any informative labelling information with those nodes. It only associates informative labels with the tree leafs. (We haven't represented any such labels in our diagreams.)
+We're understanding the `20` here in `node 20` to just be a metalanguage marker to help us theorists keep track of which node we're referring to. We're supposing the tree structure itself doesn't associate any informative labelling information with those nodes. It only associates informative labels with the tree leafs. (We haven't represented any such labels in our diagrams.)
 
 We still do need to keep track of what fills the outermost targetted position---`* filled by node 50`---because that contain a subtree of arbitrary complexity, that is not determined by the rest of this data structure.
 
@@ -167,7 +167,7 @@ Moving left in our targetted tree that's targetted on `node 50` would be a matte
 
        {parent = ...; siblings = [*; node 50; node 80]}, * filled by node 20
 
-and similarly for moving right. If the sibling list is implemented as a list zipper, you should already know how to do that. If one were designing a tree zipper for a more restricted kind of tree, however, such as a binary tree, one would probably not represented siblings with a list zipper, but with something more special-purpose and economical.
+and similarly for moving right. If the sibling list is implemented as a list zipper, you should already know how to do that. If one were designing a tree zipper for a more restricted kind of tree, however, such as a binary tree, one would probably not represent siblings with a list zipper, but with something more special-purpose and economical.
 
 Moving downward in the tree would be a matter of constructing a tree targetted on some child of `node 20`, with the first part of the targetted tree above as its parent:
 
@@ -181,9 +181,9 @@ How would we move upward in a tree? Well, we'd build a regular, untargetted tree
               node 20
            /     |    \
         /        |      \
-       lead 1  leaf 2  leaf 3
+       leaf 1  leaf 2  leaf 3
 
-We'll call this new untargetted tree `node 20`. The result of moving upward from our tree targetted on `leaf 1` would be the outermost `parent` element of that targetted tree, with `node 20` being the subtree that occupies that parent's `*` position:
+We'll call this new untargetted tree `node 20`. The result of moving upward from our previous targetter tree, targetted on `leaf 1`, would be the outermost `parent` element of that targetted tree, with `node 20` being the subtree that filling that parent's target position `*`:
 
        {
           parent = ...;