+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 @@ -37,7 +164,30 @@ 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.] +sophisticated techniques than the super-simple Option monad.] + + +Monads in General +----------------- + +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. + +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: @@ -59,7 +209,12 @@ that provides at least the following three elements: 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. + uses. [The rationale for "unit" comes from the monad laws + (see below), where the unit function serves as an identity, + just like the unit number (i.e., 1) serves as the identity + object for multiplication. The rationale for "return" comes + from a misguided desire to resonate with C programmers and + other imperative types.] 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 @@ -72,7 +227,7 @@ that provides at least the following three elements: 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 + 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. @@ -81,9 +236,9 @@ that provides at least the following three elements: 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 +* Thirdly, an operation that's often called `bind`. As we said before, 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 + 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;; @@ -105,7 +260,7 @@ that provides at least the following three elements: 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 + operator 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`. @@ -119,32 +274,22 @@ that provides at least the following three elements: 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. + (Are you beginning to realize how wierd and wonderful monads + can be?) 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: +So the "Option/Maybe monad" consists of the polymorphic `option` type, the +`unit`/return function, and the `bind` function. - # let safe_divide num den = if 0 = den then None else Some (num/den);; - val safe_divide : int -> int -> int option =

-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 =