X-Git-Url: http://lambda.jimpryor.net/git/gitweb.cgi?p=lambda.git;a=blobdiff_plain;f=week7.mdwn;h=a05d2212b34312641baa6ba6972246e039f4c5cc;hp=9f139c1648734b93cd944c15d16c095c5f0cfe52;hb=3ef22cae11ec60126584496a6923b967510e70ad;hpb=ea61c563f158b9f279a5efb28b407bc818af43d3 diff --git a/week7.mdwn b/week7.mdwn index 9f139c16..a05d2212 100644 --- a/week7.mdwn +++ b/week7.mdwn @@ -1,36 +1,164 @@ [[!toc]] -Monads ------- - -Start by (re)reading the discussion of monads in the lecture notes for -week 6 [Towards Monads](http://lambda.jimpryor.net//week6/#index4h2). -In those notes, we saw a way to separate thining 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 monad: 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 just an integer, or else some special value which -we could interpret as signaling that something had 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 -ints and int options. 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 bindary operation -on plain integers into a lifted operation that understands how to deal -with int options in a sensible way. +Towards Monads: Safe division +----------------------------- + +[This section used to be near the end of the lecture notes for week 6] + +We begin by reasoning about what should happen when someone tries to +divide by zero. This will lead us to a general programming technique +called a *monad*, which we'll see in many guises in the weeks to come. + +Integer division presupposes that its second argument +(the divisor) is not zero, upon pain of presupposition failure. +Here's what my OCaml interpreter says: + + # 12/0;; + Exception: Division_by_zero. + +So we want to explicitly allow for the possibility that +division will return something other than a number. +We'll use OCaml's `option` type, which works like this: + + # type 'a option = None | Some of 'a;; + # None;; + - : 'a option = None + # Some 3;; + - : int option = Some 3 + +So if a division is normal, we return some number, but if the divisor is +zero, we return `None`. As a mnemonic aid, we'll append a `'` to the end of our new divide function. + +
+let div' (x:int) (y:int) = + match y with + 0 -> None + | _ -> Some (x / y);; + +(* +val div' : int -> int -> int option = fun +# div' 12 2;; +- : int option = Some 6 +# div' 12 0;; +- : int option = None +# div' (div' 12 2) 3;; +Characters 4-14: + div' (div' 12 2) 3;; + ^^^^^^^^^^ +Error: This expression has type int option + but an expression was expected of type int +*) ++ +This starts off well: dividing 12 by 2, no problem; dividing 12 by 0, +just the behavior we were hoping for. But we want to be able to use +the output of the safe-division function as input for further division +operations. So we have to jack up the types of the inputs: + +
+let div' (u:int option) (v:int option) = + match u with + None -> None + | Some x -> (match v with + Some 0 -> None + | Some y -> Some (x / y));; + +(* +val div' : int option -> int option -> int option =+ +Beautiful, just what we need: now we can try to divide by anything we +want, without fear that we're going to trigger any system errors. + +I prefer to line up the `match` alternatives by using OCaml's +built-in tuple type: + ++# div' (Some 12) (Some 2);; +- : int option = Some 6 +# div' (Some 12) (Some 0);; +- : int option = None +# div' (div' (Some 12) (Some 0)) (Some 3);; +- : int option = None +*) +
+let div' (u:int option) (v:int option) = + match (u, v) with + (None, _) -> None + | (_, None) -> None + | (_, Some 0) -> None + | (Some x, Some y) -> Some (x / y);; ++ +So far so good. But what if we want to combine division with +other arithmetic operations? We need to make those other operations +aware of the possibility that one of their arguments has triggered a +presupposition failure: + +
+let add' (u:int option) (v:int option) = + match (u, v) with + (None, _) -> None + | (_, None) -> None + | (Some x, Some y) -> Some (x + y);; + +(* +val add' : int option -> int option -> int option =+ +This works, but is somewhat disappointing: the `add'` operation +doesn't trigger any presupposition of its own, so it is a shame that +it needs to be adjusted because someone else might make trouble. + +But we can automate the adjustment. The standard way in OCaml, +Haskell, etc., is to define a `bind` operator (the name `bind` is not +well chosen to resonate with linguists, but what can you do). To continue our mnemonic association, we'll put a `'` after the name "bind" as well. + ++# add' (Some 12) (Some 4);; +- : int option = Some 16 +# add' (div' (Some 12) (Some 0)) (Some 4);; +- : int option = None +*) +
+let bind' (u: int option) (f: int -> (int option)) = + match u with + None -> None + | Some x -> f x;; + +let add' (u: int option) (v: int option) = + bind' u (fun x -> bind' v (fun y -> Some (x + y)));; + +let div' (u: int option) (v: int option) = + bind' u (fun x -> bind' v (fun y -> if (0 = y) then None else Some (x / y)));; + +(* +# div' (div' (Some 12) (Some 2)) (Some 3);; +- : int option = Some 2 +# div' (div' (Some 12) (Some 0)) (Some 3);; +- : int option = None +# add' (div' (Some 12) (Some 0)) (Some 3);; +- : int option = None +*) ++ +Compare the new definitions of `add'` and `div'` closely: the definition +for `add'` shows what it looks like to equip an ordinary operation to +survive in dangerous presupposition-filled world. Note that the new +definition of `add'` does not need to test whether its arguments are +None objects or real numbers---those details are hidden inside of the +`bind'` function. + +The definition of `div'` shows exactly what extra needs to be said in +order to trigger the no-division-by-zero presupposition. [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 options, but when we're composing natural language -expression meanings, we'll need to use types like `N int`, `Det Int`, -`VP int`, and so on. But that works automatically, because we can use +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 @@ -38,377 +166,424 @@ 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 examctly is a monad? As usual, we're not going to be pedantic -about it, but for our purposes, we can consider a monad to be a system -that provides at least the following three elements: -* A way to build a complex type from some basic type. In the 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 `x` has type `int option`, then `x` is - a box that (may) contain an integer. +Monads in General +----------------- - type 'a option = None | Some of 'a;; +We've just seen 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. -* A way to turn an ordinary value into a monadic value. In Ocaml, we - did this for any integer n by mapping an arbitrary integer `n` to - the option `Some n`. To be official, we can define a function - called unit: +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 would rather not 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 defining a +`lift` operator that mapped any binary operation on plain integers +into a lifted operation that understands how to deal with `int +option`s in a sensible way. + +So what exactly is a monad? We can consider a monad to be a system +that provides at least the following three elements: - let unit x = Some x;; - val unit : 'a -> 'a option =
- let bind m f = match m with None -> None | Some n -> f n;; - val bind : 'a option -> ('a -> 'b option) -> 'b option =+The Monad Laws +-------------- - `bind` takes two arguments (a monadic object and a function from - ordinary objects to monadic objects), and returns a monadic - object. +Just like good robots, monads must obey three laws designed to prevent +them from hurting the people that use them or themselves. - Intuitively, the interpretation of what `bind` does is like this: - the first argument computes a monadic object m, which will - evaluate to a box containing some ordinary value, call it `x`. - Then the second argument uses `x` to compute a new monadic - value. Conceptually, then, we have +* **Left identity: unit is a left identity for the bind operation.** + That is, for all `f:'a -> 'b m`, where `'b 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 bind m f = (let x = unwrap m in f x);; + # let unit x = Some x;; + val unit : 'a -> 'a option =-
-# let ( * ) m f = match m with None -> None | Some n -> f n;; -val ( * ) : 'a option -> ('a -> 'b option) -> 'b option =+ (u >>= f) >>= g == u >>= (fun x -> f x >>= g) - 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 - `m * f` or `( * ) m f` instead of `* m f`. + 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`. -* Associativity: bind obeys a kind of associativity, like this: + Some examples of associativity in the option monad (bear in + mind that in the Ocaml implementation of integer division, 2/3 + evaluates to zero, throwing away the remainder): - (m * f) * g == m * (fun x -> f x * g) + # Some 3 >>= unit >>= unit;; + - : int option = Some 3 + # Some 3 >>= (fun x -> unit x >>= unit);; + - : int option = Some 3 - If you don't understand why the lambda form is necessary, you need - to look again at the type of bind. This is important. + # Some 3 >>= divide 6 >>= divide 2;; + - : int option = Some 1 + # Some 3 >>= (fun x -> divide 6 x >>= divide 2);; + - : int option = Some 1 - For an illustration of associativity in the option monad: + # Some 3 >>= divide 2 >>= divide 6;; + - : int option = None + # Some 3 >>= (fun x -> divide 2 x >>= divide 6);; + - : int option = None --# let unit x = Some x;; -val unit : 'a -> 'a option = -# unit 2 * unit;; -- : int option = Some 2 -
-Some 3 * unit * unit;; -- : int option = Some 3 -Some 3 * (fun x -> unit x * unit);; -- : int option = Some 3 -+Of course, associativity must hold for *arbitrary* functions of +type `'a -> 'b 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`. - Of course, associativity must hold for arbitrary functions of - type `'a -> M 'a`, 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 `m` - matches `None`, both computations will result in `None`; if - `m` matches `Some n`, and `f n` evalutes to `None`, then both - computations will again result in `None`; and if the value of - `f n` matches `Some r`, then both computations will evaluate - to `g r`. +* **Right identity: unit is a right identity for bind.** That is, + `u >>= unit == u` for all monad objects `u`. For instance, -* Right identity: unit is a right identity for bind. That is, - `m * unit == m` for all monad objects `m`. For instance, + # Some 3 >>= unit;; + - : int option = Some 3 + # None >>= unit;; + - : 'a option = None -
-# Some 3 * unit;; -- : int option = Some 3 --Now, if you studied algebra, you'll remember that a *monoid* is an +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 * n == n == n * 1` for all -`n`, and `(a * b) * c == a * (b * c)` for all `a`, `b`, and `c`. As +serving as the left and right identity. That is, `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 if we generalize bind so that both arguments are -of type `'a -> M 'a`, then we get plain identity laws and -associativity laws, and the monad laws are exactly like the monoid -laws (see
-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 -+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_topics/monads_in_category_theory) notes do so, for example. -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 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. +Here are some of the other general monad operations. You don't have to master these; they're collected here for your reference. -
-type 'a intension = s -> 'a;; -let unit x (w:s) = x;; +You may sometimes see: -let ann = unit 'a';; -let bill = unit 'b';; -let cam = unit 'c';; -+ u >> v -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. +That just means: -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. + u >>= fun _ -> v -Let's test compliance with the left identity law: +that is: -
-# let bind m f (w:s) = f (m w) w;; -val bind : (s -> 'a) -> ('a -> s -> 'b) -> s -> 'b =+ bind u (fun _ -> v) -We'll assume that this and the other laws always hold. +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. -We now build up some extensional meanings: +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 left w x = match (w,x) with (2,'c') -> false | _ -> true;; + # let even x = (x mod 2 = 0);; + val g : int -> bool =-# bind (unit 'a') unit 1;; -- : char = 'a' -
-let extapp fn arg w = fn w (arg w);; +`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: -extapp left ann 1;; -# - : bool = true + # 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 =+`lift2 (+)` 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. -`extapp` stands for "extensional function application". -So Ann left in world 1, but Cam didn't leave in world 2. +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`! -A transitive predicate: +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. - let saw w x y = (w < 2) && (y < x);; - extapp (extapp saw bill) ann 1;; (* true *) - extapp (extapp saw bill) ann 2;; (* false *) +In general, any lift/map operation can be relied on to satisfy these laws: -In world 1, Ann saw Bill and Cam, and Bill saw Cam. No one saw anyone -in world two. + * lift id = id + * lift (compose f g) = compose (lift f) (lift g) -Good. Now for intensions: +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: - let intapp fn arg w = fn w arg;; + List.map (fun x -> f (g x)) lst + List.map f (List.map g lst) -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. +Another general monad operation is called `ap` in Haskell---short for "apply." (They also use `<*>`, but who can remember that?) This works like this: -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: + ap [f] [x; y] = [f x; f y] + ap (Some f) (Some x) = Some (f x) --extapp left cam 2;; -# - : bool = false -
-let lift pred w arg = bind arg (fun x w -> pred w x) w;; +and so on. Here are the laws that any `ap` operation can be relied on to satisfy: -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 *) -+ ap (unit id) u = u + ap (ap (ap (unit 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 -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.) +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: -Likewise for extensional transitive predicates like "saw": + [[1]; [1;2]; [1;3]; [1;2;4]] -
-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 *) -+to: -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"): + [1; 1; 2; 1; 3; 1; 2; 4] -
-let think (w:s) (p:s->t) (x:e) = - match (x, p 2) with ('a', false) -> false | _ -> p w;; -+That is the `join` operation. -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. +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: -
-intapp (lift (intapp think - (intapp (lift left) - (unit 'b')))) - (unit 'a') -1;; (* true *) -+ lift f u = u >>= compose unit f + lift f u = ap (unit f) u + lift2 f u v = u >>= (fun x -> v >>= (fun y -> unit (f x y))) + lift2 f u v = ap (lift f u) v = ap (ap (unit f) u) v + ap u v = u >>= (fun f -> lift f v) + ap u v = lift2 id u v + join m2 = m2 >>= id + u >>= f = join (lift f u) + u >> v = u >>= (fun _ -> v) + u >> v = lift2 (fun _ -> id) u v -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 *) -+Monad outlook +------------- -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. +We're going to be using monads for a number of different things in the +weeks to come. One major 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. -*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. +But first, we'll look at several linguistic applications for monads, based +on what's called the *Reader monad*. -Finally, note that within an intensional grammar, extensional funtion -application is essentially just bind: +##[[Reader monad for Variable Binding]]## + +##[[Reader monad for Intensionality]]## -
-# let swap f x y = f y x;; -# bind cam (swap left) 2;; -- : bool = false -