XGitUrl: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=hints%2Fassignment_7_hint_5.mdwn;h=d44f824b05968d6de85e0cbc5b46ef97c77205b5;hp=882a62327762366dc361db0e9435c22c31d5cd3f;hb=8cf1fe240800a66d644f907fad8d618b014efd7d;hpb=f212354152a53c6a3ab018c7874570c600f463b9
diff git a/hints/assignment_7_hint_5.mdwn b/hints/assignment_7_hint_5.mdwn
index 882a6232..d44f824b 100644
 a/hints/assignment_7_hint_5.mdwn
+++ b/hints/assignment_7_hint_5.mdwn
@@ 1,9 +1,22 @@
+
+
+* How shall we handle \[[∃x]]? As we said, GS&V really tell us how to interpret \[[∃xPx]], but for our purposes, what they say about this can be broken naturally into two pieces, such that we represent the update of our starting set `u` with \[[∃xPx]] as:
* 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:

 u >>=_{set} \[[∃x]] >>=_{set} \[[Px]]
+ u >>= \[[∃x]] >>= \[[Px]]
+ (Extra credit: how does the discussion on pp. 2529 of GS&V bear on the possibility of this simplification?)
+
What does \[[∃x]] need to be here? Here's what they say, on the top of p. 13:
> Suppose an information state `s` is updated with the sentence ∃xPx. Possibilities in `s` in which no entity has the property P will be eliminated.
@@ 15,17 +28,16 @@
Deferring the "property P" part, this corresponds to:
u updated with \[[∃x]] ≡
 let extend_one = fun (one_dpm : bool dpm) >
 List.map (fun d > bind_dpm one_dpm (new_peg_and_assign 'x' d)) domain
 in bind_set u extend_one
+ let extend one_dpm (d : entity) =
+ dpm_bind one_dpm (new_peg_and_assign 'x' d)
+ in set_bind u (fun one_dpm > List.map (fun d > extend one_dpm d) domain)
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,60 +47,65 @@
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 \[[∃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.
+ What's going on in this proposed representation of \[[∃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 where the entity `d` we did that with doesn't have property P. (Again, consult GS&V pp. 259 for extra credit.)
 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.

 So if we just call the function `extend_one` defined above \[[∃x]], then `u` updated with \[[∃x]] updated with \[[Px]] is just:
+ If we call the function `(fun one_dom > List.map ...)` defined above \[[∃x]], then `u` updated with \[[∃x]] updated with \[[Px]] is just:
u >>= \[[∃x]] >>= \[[Px]]
or, being explicit about which "bind" operation we're representing here with `>>=`, that is:
 bind_set (bind_set u \[[∃x]]) \[[Px]]
+ set_bind (set_bind u \[[∃x]]) \[[Px]]
* Let's compare this to what \[[∃xPx]] would look like on a nondynamic semantics, for example, where we use a simple reader monad to implement variable binding. Reminding ourselves, we'd be working in a framework like this. (Here we implement environments or assignments as functions from variables to entities, instead of as lists of pairs of variables and entities. An assignment `r` here is what `fun c > List.assoc c r` would have been in [week6](
+* Let's compare this to what \[[∃xPx]] would look like on a nondynamic semantics, for example, where we use a simple Reader monad to implement variable binding. Reminding ourselves, we'd be working in a framework like this. (Here we implement environments or assignments as functions from variables to entities, instead of as lists of pairs of variables and entities. An assignment `r` here is what `fun c > List.assoc c r` would have been in [week7](
/reader_monad_for_variable_binding).)
type assignment = char > entity;;
type 'a reader = assignment > 'a;;
 let unit_reader (x : 'a) = fun r > x;;
+ let reader_unit (value : 'a) : 'a reader = fun r > value;;
 let bind_reader (u : 'a reader) (f : 'a > 'b reader) =
+ let reader_bind (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 lift (predicate : entity > bool) =
+ let getx : entity reader = fun r > r 'x';;
+
+ 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)
+ in reader_unit (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:
\[[Q]] ≡ lift q
\[[x]] ≡ getx
\[[Qx]] ≡ \[[Q]] \[[x]] ≡
fun r >
let obj = getx r
 in unit_reader (q obj)
+ in reader_unit (q obj)
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,12 +113,13 @@
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 readermonad 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 (reader_unit obj) r)
That would be the meaning of \[[∃]], which we'd use like this:
 \[[∃]] \[[Q]]
+ \[[∃]] ( \[[Q]] )
or this:
@@ 118,11 +136,12 @@
in clause r'
in let lifted_exists =
fun lifted_predicate >
 fun r > exists (fun obj > lifted_predicate (unit_reader obj) r)
+ fun r > exists (fun obj > lifted_predicate (reader_unit obj) r)
in fun bool_reader > lifted_exists (shift 'x' bool_reader)
 which we can simplify as:
+ which we can simplify to:
+
fun bool_reader >
 let shifted'' r new_value =
+ let shifted r new_value =
let r' = fun var > if var = 'x' then new_value else r var
in bool_reader r'
 in fun r > exists (shifted'' r)
+ in fun r > exists (shifted r)
This gives us a value for \[[∃x]], which we use like this:
 \[[∃x]]_{reader} ( \[[Qx]] )
+ \[[∃x]] ( \[[Qx]] )
Contrast the way we use \[[∃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 +191,11 @@
u >>= \[[∃x]] >>= \[[Qx]]
 The crucial difference in GS&V's system is that the distinctive effect of the \[[∃x]]to allocate new pegs in the store and associate variable `x` with the objects stored theredoesn't last only while interpreting clauses supplied as arguments to \[[∃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 \[[∃x]]to allocate new pegs in the store and associate variable `x` with the objects stored theredoesn't last only while interpreting some clauses supplied as arguments to \[[∃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 ∃x (man x and ∃y y is wife of x) then (x kisses y).
 > If ∃y (farmer y and ∃x y owns x) then (y beats x).
+ See the discussion on pp. 245 of GS&V.
* Can you figure out how to handle \[[not φ]] 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.