X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=week7.mdwn;h=7544425c4bbcca2c3a1b72cf0cf088199a18586f;hp=351a6d953fac41901c96823c8bf31829b51e6733;hb=HEAD;hpb=2a5b500ba1a4da0ebae07837c82810ab418a8812 diff --git a/week7.mdwn b/week7.mdwn deleted file mode 100644 index 351a6d95..00000000 --- a/week7.mdwn +++ /dev/null @@ -1,655 +0,0 @@ -[[!toc]] - - -Monads ------- - -Start by (re)reading the discussion of monads in the lecture notes for -week 6 [[Towards Monads]]. -In those notes, we saw a way to separate thinking about error -conditions (such as trying to divide by zero) from thinking about -normal arithmetic computations. We did this by making use of the -`option` type: in each place where we had something of type `int`, we -put instead something of type `int option`, which is a sum type -consisting either of one choice with an `int` payload, or else a `None` -choice which we interpret as signaling that something has gone wrong. - -The goal was to make normal computing as convenient as possible: when -we're adding or multiplying, we don't have to worry about generating -any new errors, so we do want to think about the difference between -`int`s and `int option`s. We tried to accomplish this by defining a -`bind` operator, which enabled us to peel away the `option` husk to get -at the delicious integer inside. There was also a homework problem -which made this even more convenient by mapping any binary operation -on plain integers into a lifted operation that understands how to deal -with `int option`s in a sensible way. - -[Linguitics note: Dividing by zero is supposed to feel like a kind of -presupposition failure. If we wanted to adapt this approach to -building a simple account of presupposition projection, we would have -to do several things. First, we would have to make use of the -polymorphism of the `option` type. In the arithmetic example, we only -made use of `int option`s, but when we're composing natural language -expression meanings, we'll need to use types like `N option`, `Det option`, -`VP option`, and so on. But that works automatically, because we can use -any type for the `'a` in `'a option`. Ultimately, we'd want to have a -theory of accommodation, and a theory of the situations in which -material within the sentence can satisfy presuppositions for other -material that otherwise would trigger a presupposition violation; but, -not surprisingly, these refinements will require some more -sophisticated techniques than the super-simple option monad.] - -So what exactly is a monad? We can consider a monad to be a system -that provides at least the following three elements: - -* A complex type that's built around some more basic type. Usually - the complex type will be polymorphic, and so can apply to different basic types. - In our division example, the polymorphism of the `'a option` type - provides a way of building an option out of any other type of object. - People often use a container metaphor: if `u` has type `int option`, - then `u` is a box that (may) contain an integer. - - type 'a option = None | Some of 'a;; - -* A way to turn an ordinary value into a monadic value. In OCaml, we - did this for any integer `x` by mapping it to - the option `Some x`. In the general case, this operation is - known as `unit` or `return.` Both of those names are terrible. This - operation is only very loosely connected to the `unit` type we were - discussing earlier (whose value is written `()`). It's also only - very loosely connected to the "return" keyword in many other - programming languages like C. But these are the names that the literature - uses. - - The unit/return operation is a way of lifting an ordinary object into - the monadic box you've defined, in the simplest way possible. You can think - of the singleton function as an example: it takes an ordinary object - and returns a set containing that object. In the example we've been - considering: - - let unit x = Some x;; - val unit : 'a -> 'a option = - - So `unit` is a way to put something inside of a monadic box. It's crucial - to the usefulness of monads that there will be monadic boxes that - aren't the result of that operation. In the option/maybe monad, for - instance, there's also the empty box `None`. In another (whimsical) - example, you might have, in addition to boxes merely containing integers, - special boxes that contain integers and also sing a song when they're opened. - - The unit/return operation will always be the simplest, conceptually - most straightforward way to lift an ordinary value into a monadic value - of the monadic type in question. - -* Thirdly, an operation that's often called `bind`. This is another - unfortunate name: this operation is only very loosely connected to - what linguists usually mean by "binding." In our option/maybe monad, the - bind operation is: - - let bind u f = match u with None -> None | Some x -> f x;; - val bind : 'a option -> ('a -> 'b option) -> 'b option = - - Note the type: `bind` takes two arguments: first, a monadic box - (in this case, an `'a option`); and second, a function from - ordinary objects to monadic boxes. `bind` then returns a monadic - value: in this case, a `'b option` (you can start with, e.g., `int option`s - and end with `bool option`s). - - Intuitively, the interpretation of what `bind` does is this: - the first argument is a monadic value `u`, which - evaluates to a box that (maybe) contains some ordinary value, call it `x`. - Then the second argument uses `x` to compute a new monadic - value. Conceptually, then, we have - - let bind u f = (let x = unbox u in f x);; - - The guts of the definition of the `bind` operation amount to - specifying how to unbox the monadic value `u`. In the `bind` - opertor for the option monad, we unboxed the monadic value by - matching it with the pattern `Some x`---whenever `u` - happened to be a box containing an integer `x`, this allowed us to - get our hands on that `x` and feed it to `f`. - - If the monadic box didn't contain any ordinary value, - we instead pass through the empty box unaltered. - - In a more complicated case, like our whimsical "singing box" example - from before, if the monadic value happened to be a singing box - containing an integer `x`, then the `bind` operation would probably - be defined so as to make sure that the result of `f x` was also - a singing box. If `f` also wanted to insert a song, you'd have to decide - whether both songs would be carried through, or only one of them. - - There is no single `bind` function that dictates how this must go. - For each new monadic type, this has to be worked out in an - useful way. - -So the "option/maybe monad" consists of the polymorphic `option` type, the -`unit`/return function, and the `bind` function. With the option monad, we can -think of the "safe division" operation: - - # let safe_divide num den = if 0 = den then None else Some (num/den);; - val safe_divide : int -> int -> int option = - -as basically a function from two integers to an integer, except with -this little bit of option plumbing on the side. - -A note on notation: Haskell uses the infix operator `>>=` to stand -for `bind`. Chris really hates that symbol. Following Wadler, he prefers to -use an infix five-pointed star ⋆, or on a keyboard, `*`. Jim on the other hand -thinks `>>=` is what the literature uses and students won't be able to -avoid it. Moreover, although ⋆ is OK (though not a convention that's been picked up), overloading the multiplication symbol invites its own confusion -and Jim feels very uneasy about that. If not `>>=` then we should use -some other unfamiliar infix symbol (but `>>=` already is such...) - -In any case, the course leaders will work this out somehow. In the meantime, -as you read around, wherever you see `u >>= f`, that means `bind u f`. Also, -if you ever see this notation: - - do - x <- u - f x - -That's a Haskell shorthand for `u >>= (\x -> f x)`, that is, `bind u f`. -Similarly: - - do - x <- u - y <- v - f x y - -is shorthand for `u >>= (\x -> v >>= (\y -> f x y))`, that is, `bind u (fun x --> bind v (fun y -> f x y))`. Those who did last week's homework may recognize -this. - -(Note that the above "do" notation comes from Haskell. We're mentioning it here -because you're likely to see it when reading about monads. It won't work in -OCaml. In fact, the `<-` symbol already means something different in OCaml, -having to do with mutable record fields. We'll be discussing mutation someday -soon.) - -As we proceed, we'll be seeing a variety of other monad systems. For example, another monad is the list monad. Here the monadic type is: - - # type 'a list - -The `unit`/return operation is: - - # let unit x = [x];; - val unit : 'a -> 'a list = - -That is, the simplest way to lift an `'a` into an `'a list` is just to make a -singleton list of that `'a`. Finally, the `bind` operation is: - - # let bind u f = List.concat (List.map f u);; - val bind : 'a list -> ('a -> 'b list) -> 'b list = - -What's going on here? Well, consider `List.map f u` first. This goes through all -the members of the list `u`. There may be just a single member, if `u = unit x` -for some `x`. Or on the other hand, there may be no members, or many members. In -any case, we go through them in turn and feed them to `f`. Anything that gets fed -to `f` will be an `'a`. `f` takes those values, and for each one, returns a `'b list`. -For example, it might return a list of all that value's divisors. Then we'll -have a bunch of `'b list`s. The surrounding `List.concat ( )` converts that bunch -of `'b list`s into a single `'b list`: - - # List.concat [[1]; [1;2]; [1;3]; [1;2;4]] - - : int list = [1; 1; 2; 1; 3; 1; 2; 4] - -So now we've seen two monads: the option/maybe monad, and the list monad. For any -monadic system, there has to be a specification of the complex monad type, -which will be parameterized on some simpler type `'a`, and the `unit`/return -operation, and the `bind` operation. These will be different for different -monadic systems. - -Many monadic systems will also define special-purpose operations that only make -sense for that system. - -Although the `unit` and `bind` operation are defined differently for different -monadic systems, there are some general rules they always have to follow. - - -The Monad Laws --------------- - -Just like good robots, monads must obey three laws designed to prevent -them from hurting the people that use them or themselves. - -* **Left identity: unit is a left identity for the bind operation.** - That is, for all `f:'a -> 'a m`, where `'a m` is a monadic - type, we have `(unit x) * f == f x`. For instance, `unit` is itself - a function of type `'a -> 'a m`, so we can use it for `f`: - - # let ( * ) u f = match u with None -> None | Some x -> f x;; - val ( * ) : 'a option -> ('a -> 'b option) -> 'b option = - # let unit x = Some x;; - val unit : 'a -> 'a option = - - # unit 2;; - - : int option = Some 2 - # unit 2 * unit;; - - : int option = Some 2 - - # divide 6 2;; - - : int option = Some 3 - # unit 2 * divide 6;; - - : int option = Some 3 - - # divide 6 0;; - - : int option = None - # unit 0 * divide 6;; - - : int option = None - -The parentheses is the magic for telling OCaml that the -function to be defined (in this case, the name of the function -is `*`, pronounced "bind") is an infix operator, so we write -`u * f` or `( * ) u f` instead of `* u f`. - -* **Associativity: bind obeys a kind of associativity**. Like this: - - (u * f) * g == u * (fun x -> f x * g) - - If you don't understand why the lambda form is necessary (the "fun - x" part), you need to look again at the type of `bind`. - - Some examples of associativity in the option monad: - - # Some 3 * unit * unit;; - - : int option = Some 3 - # Some 3 * (fun x -> unit x * unit);; - - : int option = Some 3 - - # Some 3 * divide 6 * divide 2;; - - : int option = Some 1 - # Some 3 * (fun x -> divide 6 x * divide 2);; - - : int option = Some 1 - - # Some 3 * divide 2 * divide 6;; - - : int option = None - # Some 3 * (fun x -> divide 2 x * divide 6);; - - : int option = None - -Of course, associativity must hold for arbitrary functions of -type `'a -> 'a m`, where `m` is the monad type. It's easy to -convince yourself that the `bind` operation for the option monad -obeys associativity by dividing the inputs into cases: if `u` -matches `None`, both computations will result in `None`; if -`u` matches `Some x`, and `f x` evalutes to `None`, then both -computations will again result in `None`; and if the value of -`f x` matches `Some y`, then both computations will evaluate -to `g y`. - -* **Right identity: unit is a right identity for bind.** That is, - `u * unit == u` for all monad objects `u`. For instance, - - # Some 3 * unit;; - - : int option = Some 3 - # None * unit;; - - : 'a option = None - - -More details about monads -------------------------- - -If you studied algebra, you'll remember that a *monoid* is an -associative operation with a left and right identity. For instance, -the natural numbers along with multiplication form a monoid with 1 -serving as the left and right identity. That is, temporarily using -`*` to mean arithmetic multiplication, `1 * u == u == u * 1` for all -`u`, and `(u * v) * w == u * (v * w)` for all `u`, `v`, and `w`. As -presented here, a monad is not exactly a monoid, because (unlike the -arguments of a monoid operation) the two arguments of the bind are of -different types. But it's possible to make the connection between -monads and monoids much closer. This is discussed in [Monads in Category -Theory](/advanced_notes/monads_in_category_theory). -See also . - -Here are some papers that introduced monads into functional programming: - -* [Eugenio Moggi, Notions of Computation and Monads](http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf): Information and Computation 93 (1). - -* [Philip Wadler. Monads for Functional Programming](http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/baastad.pdf): -in M. Broy, editor, *Marktoberdorf Summer School on Program Design Calculi*, Springer Verlag, NATO ASI Series F: Computer and systems sciences, Volume 118, August 1992. Also in J. Jeuring and E. Meijer, editors, *Advanced Functional Programming*, Springer Verlag, LNCS 925, 1995. Some errata fixed August 2001. - The use of monads to structure functional programs is described. Monads provide a convenient framework for simulating effects found in other languages, such as global state, exception handling, output, or non-determinism. Three case studies are looked at in detail: how monads ease the modification of a simple evaluator; how monads act as the basis of a datatype of arrays subject to in-place update; and how monads can be used to build parsers. - -* [Philip Wadler. The essence of functional programming](http://homepages.inf.ed.ac.uk/wadler/papers/essence/essence.ps): -invited talk, *19'th Symposium on Principles of Programming Languages*, ACM Press, Albuquerque, January 1992. - This paper explores the use monads to structure functional programs. No prior knowledge of monads or category theory is required. - Monads increase the ease with which programs may be modified. They can mimic the effect of impure features such as exceptions, state, and continuations; and also provide effects not easily achieved with such features. The types of a program reflect which effects occur. - The first section is an extended example of the use of monads. A simple interpreter is modified to support various extra features: error messages, state, output, and non-deterministic choice. The second section describes the relation between monads and continuation-passing style. The third section sketches how monads are used in a compiler for Haskell that is written in Haskell. - -There's a long list of monad tutorials on the [[Offsite Reading]] page. Skimming the titles makes me laugh. - -In the presentation we gave above---which follows the functional programming conventions---we took `unit`/return and `bind` as the primitive operations. From these a number of other general monad operations can be derived. It's also possible to take some of the others as primitive. The [Monads in Category -Theory](/advanced_notes/monads_in_category_theory) notes do so, for example. - -Here are some of the specifics. You don't have to master these; they're collected here for your reference. - -You may sometimes see: - - u >> v - -That just means: - - u >>= fun _ -> v - -that is: - - bind u (fun _ -> v) - -You could also do `bind u (fun x -> v)`; we use the `_` for the function argument to be explicit that that argument is never going to be used. - -The `lift` operation we asked you to define for last week's homework is a common operation. The second argument to `bind` converts `'a` values into `'b m` values---that is, into instances of the monadic type. What if we instead had a function that merely converts `'a` values into `'b` values, and we want to use it with our monadic type. Then we "lift" that function into an operation on the monad. For example: - - # let even x = (x mod 2 = 0);; - val g : int -> bool = - -`even` has the type `int -> bool`. Now what if we want to convert it into an operation on the option/maybe monad? - - # let lift g = fun u -> bind u (fun x -> Some (g x));; - val lift : ('a -> 'b) -> 'a option -> 'b option = - -`lift even` will now be a function from `int option`s to `bool option`s. We can -also define a lift operation for binary functions: - - # let lift2 g = fun u v -> bind u (fun x -> bind v (fun y -> Some (g x y)));; - val lift2 : ('a -> 'b -> 'c) -> 'a option -> 'b option -> 'c option = - -`lift (+)` will now be a function from `int option`s and `int option`s to `int option`s. This should look familiar to those who did the homework. - -The `lift` operation (just `lift`, not `lift2`) is sometimes also called the `map` operation. (In Haskell, they say `fmap` or `<$>`.) And indeed when we're working with the list monad, `lift f` is exactly `List.map f`! - -Wherever we have a well-defined monad, we can define a lift/map operation for that monad. The examples above used `Some (g x)` and so on; in the general case we'd use `unit (g x)`, using the specific `unit` operation for the monad we're working with. - -In general, any lift/map operation can be relied on to satisfy these laws: - - * lift id = id - * lift (compose f g) = compose (lift f) (lift g) - -where `id` is `fun x -> x` and `compose f g` is `fun x -> f (g x)`. If you think about the special case of the map operation on lists, this should make sense. `List.map id lst` should give you back `lst` again. And you'd expect these -two computations to give the same result: - - List.map (fun x -> f (g x)) lst - List.map f (List.map g lst) - -Another general monad operation is called `ap` in Haskell---short for "apply." (They also use `<*>`, but who can remember that?) This works like this: - - ap [f] [x; y] = [f x; f y] - ap (Some f) (Some x) = Some (f x) - -and so on. Here are the laws that any `ap` operation can be relied on to satisfy: - - ap (unit id) u = u - ap (ap (ap (return compose) u) v) w = ap u (ap v w) - ap (unit f) (unit x) = unit (f x) - ap u (unit x) = ap (unit (fun f -> f x)) u - -Another general monad operation is called `join`. This is the operation that takes you from an iterated monad to a single monad. Remember when we were explaining the `bind` operation for the list monad, there was a step where -we went from: - - [[1]; [1;2]; [1;3]; [1;2;4]] - -to: - - [1; 1; 2; 1; 3; 1; 2; 4] - -That is the `join` operation. - -All of these operations can be defined in terms of `bind` and `unit`; or alternatively, some of them can be taken as primitive and `bind` can be defined in terms of them. Here are various interdefinitions: - - lift f u = ap (unit f) u - lift2 f u v = ap (lift f u) v = ap (ap (unit f) u) v - ap u v = lift2 id u v - lift f u = u >>= compose unit f - lift f u = ap (unit f) u - join m2 = m2 >>= id - u >>= f = join (lift f u) - u >> v = u >>= (fun _ -> v) - u >> v = lift2 (fun _ -> id) u v - - - -Monad outlook -------------- - -We're going to be using monads for a number of different things in the -weeks to come. The first main application will be the State monad, -which will enable us to model mutation: variables whose values appear -to change as the computation progresses. Later, we will study the -Continuation monad. - -In the meantime, we'll look at several linguistic applications for monads, based -on what's called the *reader monad*. - - -The reader monad ----------------- - -Introduce - -Heim and Kratzer's "Predicate Abstraction Rule" - - - -The intensionality monad ------------------------- -... -intensional function application. In Shan (2001) [Monads for natural -language semantics](http://arxiv.org/abs/cs/0205026v1), Ken shows that -making expressions sensitive to the world of evaluation is -conceptually the same thing as making use of a *reader monad* (which -we'll see again soon). This technique was beautifully re-invented -by Ben-Avi and Winter (2007) in their paper [A modular -approach to -intensionality](http://parles.upf.es/glif/pub/sub11/individual/bena_wint.pdf), -though without explicitly using monads. - -All of the code in the discussion below can be found here: [[intensionality-monad.ml]]. -To run it, download the file, start OCaml, and say - - # #use "intensionality-monad.ml";; - -Note the extra `#` attached to the directive `use`. - -Here's the idea: since people can have different attitudes towards -different propositions that happen to have the same truth value, we -can't have sentences denoting simple truth values. If we did, then if John -believed that the earth was round, it would force him to believe -Fermat's last theorem holds, since both propositions are equally true. -The traditional solution is to allow sentences to denote a function -from worlds to truth values, what Montague called an intension. -So if `s` is the type of possible worlds, we have the following -situation: - - -
-Extensional types                 Intensional types       Examples
--------------------------------------------------------------------
-
-S         s->t                    s->t                    John left
-DP        s->e                    s->e                    John
-VP        s->e->t                 s->(s->e)->t            left
-Vt        s->e->e->t              s->(s->e)->(s->e)->t    saw
-Vs        s->t->e->t              s->(s->t)->(s->e)->t    thought
-
- -This system is modeled on the way Montague arranged his grammar. -There are significant simplifications: for instance, determiner -phrases are thought of as corresponding to individuals rather than to -generalized quantifiers. If you're curious about the initial `s`'s -in the extensional types, they're there because the behavior of these -expressions depends on which world they're evaluated at. If you are -in a situation in which you can hold the evaluation world constant, -you can further simplify the extensional types. Usually, the -dependence of the extension of an expression on the evaluation world -is hidden in a superscript, or built into the lexical interpretation -function. - -The main difference between the intensional types and the extensional -types is that in the intensional types, the arguments are functions -from worlds to extensions: intransitive verb phrases like "left" now -take intensional concepts as arguments (type s->e) rather than plain -individuals (type e), and attitude verbs like "think" now take -propositions (type s->t) rather than truth values (type t). - -The intenstional types are more complicated than the intensional -types. Wouldn't it be nice to keep the complicated types to just -those attitude verbs that need to worry about intensions, and keep the -rest of the grammar as extensional as possible? This desire is -parallel to our earlier desire to limit the concern about division by -zero to the division function, and let the other functions, like -addition or multiplication, ignore division-by-zero problems as much -as possible. - -So here's what we do: - -In OCaml, we'll use integers to model possible worlds: - - type s = int;; - type e = char;; - type t = bool;; - -Characters (characters in the computational sense, i.e., letters like -`'a'` and `'b'`, not Kaplanian characters) will model individuals, and -OCaml booleans will serve for truth values. - - type 'a intension = s -> 'a;; - let unit x (w:s) = x;; - - let ann = unit 'a';; - let bill = unit 'b';; - let cam = unit 'c';; - -In our monad, the intension of an extensional type `'a` is `s -> 'a`, -a function from worlds to extensions. Our unit will be the constant -function (an instance of the K combinator) that returns the same -individual at each world. - -Then `ann = unit 'a'` is a rigid designator: a constant function from -worlds to individuals that returns `'a'` no matter which world is used -as an argument. - -Let's test compliance with the left identity law: - - # let bind u f (w:s) = f (u w) w;; - val bind : (s -> 'a) -> ('a -> s -> 'b) -> s -> 'b = - # bind (unit 'a') unit 1;; - - : char = 'a' - -We'll assume that this and the other laws always hold. - -We now build up some extensional meanings: - - let left w x = match (w,x) with (2,'c') -> false | _ -> true;; - -This function says that everyone always left, except for Cam in world -2 (i.e., `left 2 'c' == false`). - -Then the way to evaluate an extensional sentence is to determine the -extension of the verb phrase, and then apply that extension to the -extension of the subject: - - let extapp fn arg w = fn w (arg w);; - - extapp left ann 1;; - # - : bool = true - - extapp left cam 2;; - # - : bool = false - -`extapp` stands for "extensional function application". -So Ann left in world 1, but Cam didn't leave in world 2. - -A transitive predicate: - - let saw w x y = (w < 2) && (y < x);; - extapp (extapp saw bill) ann 1;; (* true *) - extapp (extapp saw bill) ann 2;; (* false *) - -In world 1, Ann saw Bill and Cam, and Bill saw Cam. No one saw anyone -in world two. - -Good. Now for intensions: - - let intapp fn arg w = fn w arg;; - -The only difference between intensional application and extensional -application is that we don't feed the evaluation world to the argument. -(See Montague's rules of (intensional) functional application, T4 -- T10.) -In other words, instead of taking an extension as an argument, -Montague's predicates take a full-blown intension. - -But for so-called extensional predicates like "left" and "saw", -the extra power is not used. We'd like to define intensional versions -of these predicates that depend only on their extensional essence. -Just as we used bind to define a version of addition that interacted -with the option monad, we now use bind to intensionalize an -extensional verb: - - let lift pred w arg = bind arg (fun x w -> pred w x) w;; - - intapp (lift left) ann 1;; (* true: Ann still left in world 1 *) - intapp (lift left) cam 2;; (* false: Cam still didn't leave in world 2 *) - -Because `bind` unwraps the intensionality of the argument, when the -lifted "left" receives an individual concept (e.g., `unit 'a'`) as -argument, it's the extension of the individual concept (i.e., `'a'`) -that gets fed to the basic extensional version of "left". (For those -of you who know Montague's PTQ, this use of bind captures Montague's -third meaning postulate.) - -Likewise for extensional transitive predicates like "saw": - - let lift2 pred w arg1 arg2 = - bind arg1 (fun x -> bind arg2 (fun y w -> pred w x y)) w;; - intapp (intapp (lift2 saw) bill) ann 1;; (* true: Ann saw Bill in world 1 *) - intapp (intapp (lift2 saw) bill) ann 2;; (* false: No one saw anyone in world 2 *) - -Crucially, an intensional predicate does not use `bind` to consume its -arguments. Attitude verbs like "thought" are intensional with respect -to their sentential complement, but extensional with respect to their -subject (as Montague noticed, almost all verbs in English are -extensional with respect to their subject; a possible exception is "appear"): - - let think (w:s) (p:s->t) (x:e) = - match (x, p 2) with ('a', false) -> false | _ -> p w;; - -Ann disbelieves any proposition that is false in world 2. Apparently, -she firmly believes we're in world 2. Everyone else believes a -proposition iff that proposition is true in the world of evaluation. - - intapp (lift (intapp think - (intapp (lift left) - (unit 'b')))) - (unit 'a') - 1;; (* true *) - -So in world 1, Ann thinks that Bill left (because in world 2, Bill did leave). - -The `lift` is there because "think Bill left" is extensional wrt its -subject. The important bit is that "think" takes the intension of -"Bill left" as its first argument. - - intapp (lift (intapp think - (intapp (lift left) - (unit 'c')))) - (unit 'a') - 1;; (* false *) - -But even in world 1, Ann doesn't believe that Cam left (even though he -did: `intapp (lift left) cam 1 == true`). Ann's thoughts are hung up -on what is happening in world 2, where Cam doesn't leave. - -*Small project*: add intersective ("red") and non-intersective - adjectives ("good") to the fragment. The intersective adjectives - will be extensional with respect to the nominal they combine with - (using bind), and the non-intersective adjectives will take - intensional arguments. - -Finally, note that within an intensional grammar, extensional funtion -application is essentially just bind: - - # let swap f x y = f y x;; - # bind cam (swap left) 2;; - - : bool = false - -