X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=exercises%2Fassignment7.mdwn;h=719057d4e96698331c1a4cf686dc2fc14e3d307d;hp=815258955db67cbda657a315c440aec4ae01267f;hb=HEAD;hpb=bb4e4397efc09f2c282863f93f86c70e4bb87961

diff --git a/exercises/assignment7.mdwn b/exercises/assignment7.mdwn
index 81525895..719057d4 100644
--- a/exercises/assignment7.mdwn
+++ b/exercises/assignment7.mdwn
@@ -45,7 +45,7 @@ add the last pieces to make the program function.
 You can find the skeleton code [[here|/code/untyped_evaluator.ml]].
 
 The first place you need to add code is in the `free_in` function. You already
-wrote such a function [[in a previous homework|assignment5#occurs_free]], so this
+wrote such a function [[in a previous homework|exercises/assignment5-6#occurs_free]], so this
 part should be easy. The intended behavior is for the function to return results
 like this:
 
@@ -86,7 +86,7 @@ is used. What's that about?
 [[Read about Closures here.|/topics/week7_environments_and_closures]]
 
 
-So that's what's going on with those `Closure`s. In the simple code we gave you to work with, we just made these another clause in the `term` datatype. That's really not correct. `Closure`s aren't terms. The syntax for our language doesn't have any constituents that get parsed into `Closure`s. `Closure`s are only created *during the course of evaluating terms*: specifically, when a variable gets bound to an abstract, which may itself contain variables that are locally free (not bound by the abstract itself). So really we should have two datatypes, one for terms, and another for the *results* (sometimes called "values") that terms can evaluate to. `Closure`s are results, but they aren't terms. `App`s are terms, but not results. If we had primitive numbers or other constants in our language, they might be both terms and results. In the fuller code from which your homework is simplified, this is how the types are in fact defined. But it makes things more complicated. So to keep things simple for the homework, we just pretended like `Closure`s were a new, exotic kind of `term`.
+So that's what's going on with those `Closure`s. In the simple code we gave you to work with, we just made these another clause in the `term` datatype. That's really not correct. `Closure`s aren't terms. The syntax for our language doesn't have any constituents that get parsed into `Closure`s. `Closure`s are only created *during the course of evaluating terms*: specifically, when a variable gets bound to an abstract, which may itself contain variables that are locally free (not bound by the abstract itself). So really we should have two datatypes, one for terms, and another for the *results* (sometimes called "values") that terms can evaluate to. `Closure`s are results, but they aren't terms. (In later weeks, we will see more examples of results that aren't terms, but can only be generated during the course of a computation.) `App`s are terms, but not results. If we had primitive numbers or other constants in our language, they might be both terms and results. In the fuller code from which your homework is simplified, this is how the types are in fact defined. But it makes things more complicated. So to keep things simple for the homework, we just pretended like `Closure`s were a new, exotic kind of `term`.
 
 In any case, now you know what's going on with the `Closure`s, and you should be able to complete the missing pieces of the `eval` function in the code skeleton linked above.