X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?a=blobdiff_plain;ds=inline;f=hints%2Fassignment_7_hint_5.mdwn;h=acbc901579bd5d9c5aa35aea3a5a5c0a6c4cb4d1;hb=ee6e8e390ac5ffa57dc95531939222efda5d37ff;hp=120c1fdb6dbcbd2768935f35399740f1a5de0fd1;hpb=60fde0202775a36c5b20c370374649d2a90c6af8;p=lambda.git diff --git a/hints/assignment_7_hint_5.mdwn b/hints/assignment_7_hint_5.mdwn index 120c1fdb..acbc9015 100644 --- a/hints/assignment_7_hint_5.mdwn +++ b/hints/assignment_7_hint_5.mdwn @@ -1,9 +1,10 @@ - -* 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: +* 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:
u >>= \[[∃x]] >>= \[[Px]]
+ (Extra credit: how does the discussion on pp. 25-29 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,9 +16,9 @@
Deferring the "property P" part, this corresponds to:
u updated with \[[∃x]] ≡
- 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
+ let extend one_dpm (d : entity) =
+ bind_dpm one_dpm (new_peg_and_assign 'x' d)
+ in bind_set 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):
@@ -36,11 +37,9 @@
(* we pass through the same truth_value that we started with *)
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.
-
- A later step can then filter out all the `dpm`s where the entity `d` we did that with doesn't have property P.
+ 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. 25-9 for extra credit.)
- 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]]
@@ -50,7 +49,7 @@
bind_set (bind_set u \[[∃x]]) \[[Px]]
-* Let's compare this to what \[[∃xPx]] would look like on a non-dynamic 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 non-dynamic 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;;
@@ -108,7 +107,7 @@
That would be the meaning of \[[∃]], which we'd use like this:
- \[[∃]] \[[Q]]
+ \[[∃]] ( \[[Q]] )
or this:
@@ -128,8 +127,9 @@
fun r -> exists (fun obj -> lifted_predicate (unit_reader 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:
@@ -178,10 +179,12 @@
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 there---doesn'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'll 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 there---doesn'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).
+ See the discussion on pp. 24-5 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.