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

diff --git a/hints/assignment_7_hint_5.mdwn b/hints/assignment_7_hint_5.mdwn
index af3c9476..120c1fdb 100644
--- a/hints/assignment_7_hint_5.mdwn
+++ b/hints/assignment_7_hint_5.mdwn
@@ -1,7 +1,7 @@
 
 *	How shall we handle \[[∃x]]? As we said, GS&V really tell us how to interpret \[[∃xPx]], but what they say about this breaks naturally into two pieces, such that we can represent the update of our starting set `u` with \[[∃xPx]] as:
 
-	<pre><code>u >>=<sub>set</sub> \[[&exist;x]] >>=<sub>set</sub> \[[Px]]
+	<pre><code>u >>= \[[&exist;x]] >>= \[[Px]]
 	</code></pre>
 
 	What does \[[&exist;x]] need to be here? Here's what they say, on the top of p. 13:
@@ -15,17 +15,16 @@
 	Deferring the "property P" part, this corresponds to:
 
 	<pre><code>u updated with \[[&exist;x]] &equiv;
-		let extend_one = fun (one_dpm : bool dpm) ->
+		let extend_one : clause = fun one_dpm ->
 			List.map (fun d -> bind_dpm one_dpm (new_peg_and_assign 'x' d)) domain
 		in bind_set u extend_one
 	</code></pre>
 
 	where `new_peg_and_assign` is the operation we defined in [hint 3](/hints/assignment_7_hint_3):
 
-		let new_peg_and_assign (var_to_bind : char) (d : entity) =
-			(* we want to return a function that we can bind to a bool dpm *)
-			fun (truth_value : bool) ->
-				fun ((r, h) : assignment * store) ->
+		let new_peg_and_assign (var_to_bind : char) (d : entity) : bool -> bool dpm =
+			fun truth_value ->
+				fun (r, h) ->
 					(* first we calculate an unused index *)
 					let new_index = List.length h
 					(* next we store d at h[new_index], which is at the very end of h *)
@@ -35,11 +34,11 @@
 					in let r' = fun var ->
 						if var = var_to_bind then new_index else r var
 					(* we pass through the same truth_value that we started with *)
-					in (truth_value, r', h')
+					in (truth_value, r', h');;
 	
 	What's going on in this representation of `u` updated with \[[&exist;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 \[[&exist;x]], then `u` updated with \[[&exist;x]] updated with \[[Px]] is just:
 
@@ -57,23 +56,31 @@
 		type assignment = char -> entity;;
 		type 'a reader = assignment -> 'a;;
 
-		let unit_reader (x : 'a) = fun r -> x;;
+		let unit_reader (value : 'a) : 'a reader = fun r -> value;;
 
-		let bind_reader (u : 'a reader) (f : 'a -> 'b reader) =
+		let bind_reader (u : 'a reader) (f : 'a -> 'b reader) : 'b reader =
 			fun r ->
 				let a = u r
 				in let u' = f a
 				in u' r;;
 
-		let getx = fun r -> r 'x';;
+	Here the type of a sentential clause is:
+
+		type clause = bool reader;;
+
+	Here are meanings for singular terms and predicates:
+
+		let getx : entity reader = fun r -> r 'x';;
 
-		let lift (predicate : entity -> bool) =
+		type lifted_unary = entity reader -> bool reader;;
+
+		let lift (predicate : entity -> bool) : lifted_unary =
 			fun entity_reader ->
 				fun r ->
 					let obj = entity_reader r
 					in unit_reader (predicate obj)
 
-	`lift predicate` converts a function of type `entity -> bool` into one of type `entity reader -> bool reader`. The meaning of \[[Qx]] would then be:
+	The meaning of \[[Qx]] would then be:
 
 	<pre><code>\[[Q]] &equiv; lift q
 	\[[x]] &equiv; getx
@@ -85,10 +92,9 @@
 
 	Recall also how we defined \[[lambda x]], or as [we called it before](/reader_monad_for_variable_binding), \\[[who(x)]]:
 
-		let shift (var_to_bind : char) (clause : bool reader) =
-			(* we return a lifted predicate, that is a entity reader -> bool reader *)
+		let shift (var_to_bind : char) (clause : clause) : lifted_unary =
 			fun entity_reader ->
-				fun (r : assignment) ->
+				fun r ->
 					let new_value = entity_reader r
 					(* remember here we're implementing assignments as functions rather than as lists of pairs *)
 					in let r' = fun var -> if var = var_to_bind then new_value else r var
@@ -96,8 +102,9 @@
 
 	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 (lifted_predicate : lifted_unary) ->
+			fun r -> exists (fun (obj : entity) ->
+				lifted_predicate (unit_reader obj) r)
 			
 	That would be the meaning of \[[&exist;]], which we'd use like this:
 
@@ -163,7 +170,7 @@
 
 	This gives us a value for \[[&exist;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 +178,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;x (man x and &exist;y y is wife of x) then (x kisses y).
 
-	>	If &exist;y (farmer y and &exist;x y owns x) then (y beats x).
 
+*	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.
 
-*	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.