2 I would like to propose one pedegogical suggestion (due to Ken), which
3 is to separate peg addition from non-determinacy by explicitly adding
4 a "Let" construction to GSV's logic, i.e., "Let of var * term *
5 clause", whose interpretation adds a peg, assigns var to it, sets the
6 value to the value computed by term, and evaluates the clause with the
7 new peg in place. This can be added easily, especially since you have
8 supplied a procedure that handles the main essence of the
9 construction. Once the Let is in place, adding the existential is
10 purely dealing with nondeterminism.
13 * 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:
15 <pre><code>u >>= \[[∃x]] >>= \[[Px]]
18 (Extra credit: how does the discussion on pp. 25-29 of GS&V bear on the possibility of this simplification?)
20 What does \[[∃x]] need to be here? Here's what they say, on the top of p. 13:
22 > 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.
24 We can defer that to a later step, where we do `... >>= \[[Px]]`. GS&V continue:
26 > 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.
28 Deferring the "property P" part, this corresponds to:
30 <pre><code>u updated with \[[∃x]] ≡
31 let extend one_dpm (d : entity) =
32 dpm_bind one_dpm (new_peg_and_assign 'x' d)
33 in set_bind u (fun one_dpm -> List.map (fun d -> extend one_dpm d) domain)
36 where `new_peg_and_assign` is the operation we defined in [hint 3](/hints/assignment_7_hint_3):
38 let new_peg_and_assign (var_to_bind : char) (d : entity) : bool -> bool dpm =
41 (* first we calculate an unused index *)
42 let new_index = List.length h
43 (* next we store d at h[new_index], which is at the very end of h *)
44 (* the following line achieves that in a simple but inefficient way *)
45 in let h' = List.append h [d]
46 (* next we assign 'x' to location new_index *)
47 in let r' = fun var ->
48 if var = var_to_bind then new_index else r var
49 (* we pass through the same truth_value that we started with *)
50 in (truth_value, r', h');;
52 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.)
54 If we call the function `(fun one_dom -> List.map ...)` defined above \[[∃x]], then `u` updated with \[[∃x]] updated with \[[Px]] is just:
56 <pre><code>u >>= \[[∃x]] >>= \[[Px]]
59 or, being explicit about which "bind" operation we're representing here with `>>=`, that is:
61 <pre><code>set_bind (set_bind u \[[∃x]]) \[[Px]]
64 * 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](
65 /reader_monad_for_variable_binding).)
67 type assignment = char -> entity;;
68 type 'a reader = assignment -> 'a;;
70 let reader_unit (value : 'a) : 'a reader = fun r -> value;;
72 let reader_bind (u : 'a reader) (f : 'a -> 'b reader) : 'b reader =
78 Here the type of a sentential clause is:
80 type clause = bool reader;;
82 Here are meanings for singular terms and predicates:
84 let getx : entity reader = fun r -> r 'x';;
86 type lifted_unary = entity reader -> bool reader;;
88 let lift (predicate : entity -> bool) : lifted_unary =
91 let obj = entity_reader r
92 in reader_unit (predicate obj)
94 The meaning of \[[Qx]] would then be:
96 <pre><code>\[[Q]] ≡ lift q
98 \[[Qx]] ≡ \[[Q]] \[[x]] ≡
101 in reader_unit (q obj)
104 Recall also how we defined \[[lambda x]], or as [we called it before](/reader_monad_for_variable_binding), \\[[who(x)]]:
106 let shift (var_to_bind : char) (clause : clause) : lifted_unary =
109 let new_value = entity_reader r
110 (* remember here we're implementing assignments as functions rather than as lists of pairs *)
111 in let r' = fun var -> if var = var_to_bind then new_value else r var
114 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:
116 fun (lifted_predicate : lifted_unary) ->
117 fun r -> exists (fun (obj : entity) ->
118 lifted_predicate (reader_unit obj) r)
120 That would be the meaning of \[[∃]], which we'd use like this:
122 <pre><code>\[[∃]] ( \[[Q]] )
127 <pre><code>\[[∃]] ( \[[lambda x]] \[[Qx]] )
130 If we wanted to compose \[[∃]] with \[[lambda x]], we'd get:
132 let shift var_to_bind clause =
133 fun entity_reader r ->
134 let new_value = entity_reader r
135 in let r' = fun var -> if var = var_to_bind then new_value else r var
137 in let lifted_exists =
138 fun lifted_predicate ->
139 fun r -> exists (fun obj -> lifted_predicate (reader_unit obj) r)
140 in fun bool_reader -> lifted_exists (shift 'x' bool_reader)
142 which we can simplify to:
146 fun entity_reader r ->
147 let new_value = entity_reader r
148 in let r' = fun var -> if var = 'x' then new_value else r var
150 in let lifted_exists =
151 fun lifted_predicate ->
152 fun r -> exists (fun obj -> lifted_predicate (reader_unit obj) r)
153 in fun bool_reader -> lifted_exists (shifted bool_reader)
157 fun entity_reader r ->
158 let new_value = entity_reader r
159 in let r' = fun var -> if var = 'x' then new_value else r var
161 in fun r -> exists (fun obj -> shifted' (reader_unit obj) r)
164 let shifted'' r obj =
165 let new_value = (reader_unit obj) r
166 in let r' = fun var -> if var = 'x' then new_value else r var
168 in fun r -> exists (fun obj -> shifted'' r obj)
171 let shifted'' r obj =
173 in let r' = fun var -> if var = 'x' then new_value else r var
175 in fun r -> exists (shifted'' r)
179 let shifted r new_value =
180 let r' = fun var -> if var = 'x' then new_value else r var
182 in fun r -> exists (shifted r)
184 This gives us a value for \[[∃x]], which we use like this:
186 <pre><code>\[[∃x]] ( \[[Qx]] )
189 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:
191 <pre><code>u >>= \[[∃x]] >>= \[[Qx]]
194 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:
196 > If ∃x (man x and ∃y y is wife of x) then (x kisses y).
198 See the discussion on pp. 24-5 of GS&V.
201 * 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.