X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?a=blobdiff_plain;ds=inline;f=hints%2Fassignment_7_hint_5.mdwn;h=40df3b81971f5b8c31139c6fcfd7bc942fbdce24;hb=230b5dcd46453e852f748a63ebb5eff8e16e10e0;hp=591fd31d9421859776cb4220a92ecb8a3076f16e;hpb=26574827b88c32f00baaf941c4eac1aaebac839d;p=lambda.git diff --git a/hints/assignment_7_hint_5.mdwn b/hints/assignment_7_hint_5.mdwn index 591fd31d..40df3b81 100644 --- a/hints/assignment_7_hint_5.mdwn +++ b/hints/assignment_7_hint_5.mdwn @@ -1,49 +1,45 @@ +* 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. 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.
- We can defer that to a later step, where we do `... >>= \[[Px]]`.
+ We can defer that to a later step, where we do `... >>= \[[Px]]`. GS&V continue:
- > The referent system of the remaining possibilities will be extended with a new peg, which is associated with `x`. And for each old possibility `i` in `s`, there will be just as many extensions `i[x/d]` in the new state `s'` and there are entities `d` which in the possible world of `i` have the property P.
+ > The referent system of the remaining possibilities will be extended with a new peg, which is associated with `x`. And for each old possibility `i` in `s`, there will be just as many extensions `i[x/d]` in the new state `s'` as there are entities `d` which in the possible world of `i` have the property P.
Deferring the "property P" part, this corresponds to:
u updated with \[[∃x]] ≡
- let extend_one = fun one_dpm ->
- fun truth_value ->
- if truth_value = false
- then empty_set
- else List.map (fun d -> 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):
- let new_peg_and_assign (var_to_bind : char) (d : entity) =
- fun ((r, h) : assignment * store) ->
- (* first we calculate an unused index *)
- let newindex = List.length h
- (* next we store d at h[newindex], which is at the very end of h *)
- (* the following line achieves that in a simple but inefficient way *)
- in let h' = List.append h [d]
- (* next we assign 'x' to location newindex *)
- in let r' = fun v ->
- if v = var_to_bind then newindex else r v
- (* the reason for returning true as an initial element should now be apparent *)
- in (true, r',h')
+ 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 *)
+ (* the following line achieves that in a simple but inefficient way *)
+ in let h' = List.append h [d]
+ (* next we assign 'x' to location new_index *)
+ 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');;
- What's going on here? For each `bool dpm` in `u` that wraps a `true`, we collect `dpm`s that are the result of 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. For `bool dpm`s in `u` that wrap `false`, we just discard them. We could if we wanted instead return `unit_set (unit_dpm false)`.
-
- 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.
+ 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]]
@@ -53,4 +49,142 @@ entity `d` we did that with doesn't have property P.
bind_set (bind_set u \[[∃x]]) \[[Px]]
-* Can you figure out how to handle \[[not φ]] on your own? If not, here are some [more hints](/hints/assignment_7_hint_6).
+* 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](
+/reader_monad_for_variable_binding).)
+
+ type assignment = char -> entity;;
+ type 'a reader = assignment -> 'a;;
+
+ let unit_reader (value : 'a) : 'a reader = fun r -> value;;
+
+ 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;;
+
+ 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';;
+
+ 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)
+
+ 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)
+
+
+ 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 : clause) : lifted_unary =
+ fun entity_reader ->
+ 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
+ in clause r'
+
+ 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 : lifted_unary) ->
+ fun r -> exists (fun (obj : entity) ->
+ lifted_predicate (unit_reader obj) r)
+
+ That would be the meaning of \[[∃]], which we'd use like this:
+
+ \[[∃]] ( \[[Q]] )
+
+
+ or this:
+
+ \[[∃]] ( \[[lambda x]] \[[Qx]] )
+
+
+ If we wanted to compose \[[∃]] with \[[lambda x]], we'd get:
+
+ let shift var_to_bind clause =
+ fun entity_reader r ->
+ let new_value = entity_reader r
+ in let r' = fun var -> if var = var_to_bind then new_value else r var
+ in clause r'
+ in let lifted_exists =
+ fun lifted_predicate ->
+ 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 to:
+
+
+
+ fun bool_reader ->
+ 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)
+
+ This gives us a value for \[[∃x]], which we use like this:
+
+ \[[∃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:
+
+ 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 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.
+