From 04d087d808a22b3c6d863a6f08371daef52534fc Mon Sep 17 00:00:00 2001 From: jim Date: Fri, 20 Mar 2015 10:36:05 -0400 Subject: [PATCH 1/1] expanding --- topics/week7_introducing_monads.mdwn | 78 +++++++++++++++++++++++++++++++----- 1 file changed, 67 insertions(+), 11 deletions(-) diff --git a/topics/week7_introducing_monads.mdwn b/topics/week7_introducing_monads.mdwn index 5f822866..e4dae12e 100644 --- a/topics/week7_introducing_monads.mdwn +++ b/topics/week7_introducing_monads.mdwn @@ -83,12 +83,18 @@ For instance, the following are Kleisli arrows: In the first, `P` has become `int` and `Q` has become `bool`. (The boxed type Q is bool). -Note that the left-hand schema `P` is permitted to itself be a boxed type. That is, where -if `α list` is our box type, we can write the second type as: +Note that the left-hand schema `P` is permitted to itself be a boxed type. That is, where if `α list` is our box type, we can write the second type as: int -> int list -As semanticists, you are no doubt familiar with the debates between those who insist that propositions are sets of worlds and those who insist they are context change potentials. We hope to show you, in coming weeks, that propositions are (certain sorts of) Kleisli arrows. But this doesn't really compete with the other proposals; it is a generalization of them. Both of the other proposed structures can be construed as specific Kleisli arrows. +Here are some examples of values of these Kleisli arrow types, where the box type is `α list`, and the Kleisli arrow types are int -> int (that is, `int -> int list`) or int -> bool: + +
\x. [x]
+\x. [odd? x, odd? x]
+\x. prime_factors_of x
+\x. [0, 0, 0]
+ +As semanticists, you are no doubt familiar with the debates between those who insist that propositions are sets of worlds and those who insist they are context change potentials. We hope to show you, in coming weeks, that propositions are (certain sorts of) Kleisli arrows. But this doesn't really compete with the other proposals; it is a generalization of them. Both of the other proposed structures can be construed as specific Kleisli arrow types. ## A family of functions for each box type ## @@ -99,21 +105,35 @@ Here are the types of our crucial functions, together with our pronunciation, an map (/mæp/): (P -> Q) -> P -> Q +> In Haskell, this is the function `fmap` from the `Prelude` and `Data.Functor`; also called `<$>` in `Data.Functor` and `Control.Applicative`, and also called `Control.Applicative.liftA` and `Control.Monad.liftM`. + map2 (/mæptu/): (P -> Q -> R) -> P -> Q -> R -mid (/εmaidεnt@tI/ aka unit, return, pure): P -> P +> In Haskell, this is called `Control.Applicative.liftA2` and `Control.Monad.liftM2`. + +mid (/εmaidεnt@tI/): P -> P + +> In Haskell, this is called `Control.Monad.return` and `Control.Applicative.pure`. In other theoretical contexts it is sometimes called `unit` or `η`. In the class presentation Jim called it `𝟭`. This notion is exemplified by `Just` for the box type `Maybe α` and by the singleton function for the box type `List α`. m$ or mapply (/εm@plai/): P -> Q -> P -> Q +> In Haskell, this is called `Control.Monad.ap` or `Control.Applicative.<*>`. In the class presentation Jim called it `●`. + <=< or mcomp : (Q -> R) -> (P -> Q) -> (P -> R) +> In Haskell, this is `Control.Monad.<=<`. + >=> (flip mcomp, should we call it mpmoc?): (P -> Q) -> (Q -> R) -> (P -> R) +> In Haskell, this is `Control.Monad.>=>`. + >>= or mbind : (Q) -> (Q -> R) -> (R) =<< (flip mbind, should we call it mdnib?) (Q -> R) -> (Q) -> (R) -join: P -> P +join: P -> P + +> In Haskell, this is `Control.Monad.join`. In other theoretical contexts it is sometimes called `μ`. In the class handout, we gave the types for `>=>` twice, and once was correct but the other was a typo. The above is the correct typing. @@ -122,9 +142,7 @@ Haskell's name "bind" for `>>=` is not well chosen from our perspective, but thi Haskell's names "return" and "pure" for `mid` are even less well chosen, and we think it will be clearer in our discussion to use a different name. (Also, in other theoretical contexts this notion goes by other names, anyway, like `unit` or `η` --- having nothing to do with `η`-reduction in the Lambda Calculus.) In the handout we called `mid` `𝟭`. But now we've decided that `mid` is better. (Think of it as "m" plus "identity", not as the start of "midway".) -The menagerie isn't quite as bewildering as you might suppose. Many of these will -be interdefinable. For example, here is how `mcomp` and `mbind` are related: k <=< j ≡ -\a. (j a >>= k). +The menagerie isn't quite as bewildering as you might suppose. Many of these will be interdefinable. For example, here is how `mcomp` and `mbind` are related: k <=< j ≡ \a. (j a >>= k). We will move freely back and forth between using `>=>` and using `<=<` (aka `mcomp`), which is just `>=>` with its arguments flipped. `<=<` has the virtue that it corresponds more @@ -187,15 +205,53 @@ has to obey the following Map Laws: > 
μ ○ M(μ) == μ ○ μ
μ ○ η == id == μ ○ M(η)
-Here are some interdefinitions: TODO -Names in Haskell: TODO +## Interdefinitions and Subsidiary notions## + +We said above that various of these box type operations can be defined in terms of others. Here is a list of various ways in which they're related. We try to stick to the consistent typing conventions that: + +
+f : α -> β; g and h have types of the same format (note that α and β are permitted to be, but needn't be, boxed types)
+j : α -> β; k and l have types of the same format
+u : α; v and xs and ys have types of the same format
+w : α
+
+ +But we may sometimes slip. + +Here are some ways the different notions are related: + +
+j >=> k ≡= \a. (j a >>= k)
+u >>= k == (id >=> k) u; or ((\(). u) >=> k) ()
+u >>= k == join (map k u)
+join w == w >>= id
+map2 f xs ys == xs >>= (\x. ys >>= (\y. mid (f x y)))
+map2 f xs ys == (map f xs) m$ ys, using m$ as an infix operator
+fs m$ xs == fs >>= (\f. map f xs)
+m$ == map2 id
+map f xs == mid f m$ xs
+map f u == u >>= mid ○ f
+
+ + +Here are some other monadic notion that you may sometimes encounter: + +* mzero is a value of type α that is exemplified by `Nothing` for the box type `Maybe α` and by `[]` for the box type `List α`. It has the behavior that `anything m$ mzero == mzero == mzero m$ anything == mzero >>= anything`. In Haskell, this notion is called `Control.Applicative.empty` or `Control.Monad.mzero`. + +* Haskell has a notion `>>` definable as `\u v. mid (const id) m$ u m$ v`. It works like this: `u >> v == u >>= const v`. This is often useful, and won't in general be identical to just `v`. For example, using the box type `List α`, `[1,2,3] >> [4,5] == [4,5,4,5,4,5]`. But in the special case of `mzero`, it is a consequence of what we said above that `anything >> mzero == mzero`. Haskell also calls `>>` `Control.Applicative.*>`. + +* Haskell has a correlative notion `Control.Applicative.<*`, definable as `\u v. mid const m$ u m$ v`. For example, `[1,2,3] <* [4,5] == [1,1,2,2,3,3]`. You might expect Haskell to call `<*` `<<`, but they don't. They used to use `<<` for `flip (>>)` instead, but now they seem not to use it anymore. Maybe in the future they'll call `<*` `<<`. + +* mapconst is definable as `map ○ const`. For example `mapconst 4 [1,2,3] == [4,4,4]`. Haskell calls `mapconst` `<$` in `Data.Functor` and `Control.Applicative`. They also use `$>` for `flip mapconst`, and `Control.Monad.void` for `mapconst ()`. + + ## Examples ## To take a trivial (but, as we will see, still useful) example, consider the Identity box type: `α`. So if `α` is type `bool`, -then a boxed `α` is ... a `bool`. That is, α = α. +then a boxed `α` is ... a `bool`. That is, α == α. In terms of the box analogy, the Identity box type is a completely invisible box. With the following definitions: -- 2.11.0