From: jim Date: Wed, 29 Apr 2015 15:07:25 +0000 (-0400) Subject: add more anchors X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=commitdiff_plain;h=bca07cf5fabdd3a27119dba460314b342d8ccc0d add more anchors --- diff --git a/exercises/assignment12.mdwn b/exercises/assignment12.mdwn index 1d135b47..58e5096a 100644 --- a/exercises/assignment12.mdwn +++ b/exercises/assignment12.mdwn @@ -117,6 +117,7 @@ Here are the beginnings of functions to move from one focused tree to another: 1. Your first assignment is to complete the definitions of `move_botleft` and `move_right_or_up`. (Really it should be `move_right_or_up_..._and_right`.) + Having completed that, we can use define a function that enumerates a tree's fringe, step by step, until it's exhausted: let make_fringe_enumerator (t: 'a tree) = @@ -192,6 +193,7 @@ Here are the beginnings of functions to move from one focused tree to another: 3. Now we'll talk about another way to implement the `make_fringe_enumerator` function above (and so too the `same_fringe` function which uses it). Notice that the pattern given above is that the `make_fringe_enumerator` creates a `next_leaf` function and an initial state, and each time you want to advance the `next_leaf` by one step, you do so by calling it with the current state. It will return a leaf label plus a modified state, which you can use when you want to call it again and take another step. All of the `next_leaf` function's memory about where it is in the enumeration is contained in the state. If you saved an old state, took three steps, and then called the `next_leaf` function again with the saved old state, it would be back where it was three steps ago. But in fact, the way we use the `next_leaf` function and state above, there is no back-tracking. Neither do we "fork" any of the states and pursue different forward paths. Their progress is deterministic, and fixed independently of anything that `same_fringe` might do. All that's up to `same_fringe` is to take the decision of when (and whether) to take another step forward. Given that usage pattern, it would be appropriate and convenient to make the `next_leaf` function remember its state itself, in a mutable variable. The client function `same_fringe` doesn't need to do anything with, or even be given access to, this variable. Here's how we might write `make_fringe_enumerator` according to this plan: + let make_fringe_enumerator (t: 'a tree) = (* create a zipper focusing the botleft of t *)