X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=hints%2Fassignment_7_hint_5.mdwn;h=a0ac32a3e8066a71968a56684027591a2eff228c;hp=af3c947692681dca251dab87ff4967948d6caf11;hb=efa4651049a770c2935ebc11770bbdb23b8a3c6d;hpb=56875febe11ea5c63e753b64c546a7a45f28e343

diff --git a/hints/assignment_7_hint_5.mdwn b/hints/assignment_7_hint_5.mdwn
index af3c9476..a0ac32a3 100644
--- a/hints/assignment_7_hint_5.mdwn
+++ b/hints/assignment_7_hint_5.mdwn
@@ -39,7 +39,7 @@
 	
 	What's going on in this representation of `u` updated with \[[∃x]]? For each `bool dpm` in `u`, we collect `dpm`s that are the result of passing through their `bool`, but extending their input `(r, h)` by allocating a new peg for entity `d`, for each `d` in our whole domain of entities, and binding the variable `x` to the index of that peg.
 
-	A later step can then filter out all the `dpm`s according to which the entity `d` we did that with doesn't have property P.
+	A later step can then filter out all the `dpm`s where the entity `d` we did that with doesn't have property P.
 
 	So if we just call the function `extend_one` defined above \[[∃x]], then `u` updated with \[[∃x]] updated with \[[Px]] is just:
 
@@ -97,7 +97,8 @@
 	Now, how would we implement quantifiers in this setting? I'll assume we have a function `exists` of type `(entity -> bool) -> bool`. That is, it accepts a predicate as argument and returns `true` if any element in the domain satisfies that predicate. We could implement the reader-monad version of that like this:
 
 		fun (lifted_predicate : entity reader -> bool reader) ->
-			fun r -> exists (fun (obj : entity) -> lifted_predicate (unit_reader obj) r)
+			fun r -> exists (fun (obj : entity) ->
+				lifted_predicate (unit_reader obj) r)
 			
 	That would be the meaning of \[[∃]], which we'd use like this:
 
@@ -163,7 +164,7 @@
 
 	This gives us a value for \[[∃x]], which we use like this:
 
-	<pre><code>\[[&exist;x]]<sub>reader</sub> ( \[[Qx]] )
+	<pre><code>\[[&exist;x]] ( \[[Qx]] )
 	</code></pre>
 
 	Contrast the way we use \[[&exist;x]] in GS&V's system. Here we don't have a function that takes \[[Qx]] as an argument. Instead we have a operation that gets bound in a discourse chain:
@@ -171,9 +172,10 @@
 	<pre><code>u >>= \[[&exist;x]] >>= \[[Qx]]
 	</code></pre>
 
-	The crucial difference in GS&V's system is that the distinctive effect of the \[[&exist;x]]---to allocate new pegs in the store and associate variable `x` with the objects stored there---doesn't last only while interpreting clauses supplied as arguments to \[[&exist;x]]. Instead, it persists through the discourse, possibly affecting the interpretation of claims outside the logical scope of the quantifier. This is how we're able to interpret claims like:
+	The crucial difference in GS&V's system is that the distinctive effect of the \[[&exist;x]]---to allocate new pegs in the store and associate variable `x` with the objects stored there---doesn't last only while interpreting clauses supplied as arguments to \[[&exist;x]]. Instead, it persists through the discourse, possibly affecting the interpretation of claims outside the logical scope of the quantifier. This is how we'll able to interpret claims like:
 
-	>	If &exist;y (farmer y and &exist;x y owns x) then (y beats x).
+	>	If &exist;x (man x and &exist;y y is wife of x) then (x kisses y).
 
 
-*	Can you figure out how to handle \[[not &phi;]] on your own? If not, here are some [more hints](/hints/assignment_7_hint_6). But try to get as far as you can on your own.
+*	Can you figure out how to handle \[[not &phi;]] and the other connectives? If not, here are some [more hints](/hints/assignment_7_hint_6). But try to get as far as you can on your own.
+