+In words, `mcomp k j a` feeds the `a` (which has type `α`) to `j`, which returns a list of `β`s;
+each `β` in that list is fed to `k`, which returns a list of `γ`s. The
+final result is the concatenation of those lists of `γ`s.
+
+For example:
+
+ let j a = [a*a, a+a] in
+ let k b = [b, b+1] in
+ mcomp k j 7 ==> [49, 50, 14, 15]
+
+`j 7` produced `[49, 14]`, which after being fed through `k` gave us `[49, 50, 14, 15]`.
+
+Contrast that to `m$` (`mapply`), which operates not on two *box-producing functions*, but instead on two *boxed type values*, one containing functions to be applied to the values in the other box, via some predefined scheme. Thus:
+
+ let js = [(\a->a*a),(\a->a+a)] in
+ let xs = [7, 5] in
+ mapply js xs ==> [49, 25, 14, 10]
+
+
+The question came up in class of when box types might fail to be Mappable, or Mappables might fail to be MapNables, or MapNables might fail to be Monads.
+
+For the first failure, we noted that it's easy to define a `map` operation for the box type `R -> α`, for a fixed type `R`. You `map` a function of type `P -> Q` over a value of the boxed type <code><u>P</u></code>, that is a value of type `R -> P`, by just returning a function that takes some `R` as input, first supplies it to your `R -> P` value, and then supplies the result to your `map`ped function of type `P -> Q`. (We will be working with this Mappable extensively; in fact it's not just a Mappable but more specifically a Monad.)
+
+But if on the other hand, your box type is `α -> R`, you'll find that there is no way to define a `map` operation that takes arbitrary functions of type `P -> Q` and values of the boxed type <code><u>P</u></code>, that is `P -> R`, and returns values of the boxed type <code><u>Q</u></code>.
+
+For the second failure, that is cases of Mappables that are not MapNables, we cited box types like `(R, α)`, for arbitrary fixed types `R`. The `map` operation for these is defined by `map f (r,a) = (r, f a)`. For certain choices of `R` these can be MapNables too. The easiest case is when `R` is the type of `()`. But when we look at the MapNable Laws, we'll see that they impose constraints we cannot satisfy for *every* choice of the fixed type `R`. Here's why. We'll need to define `mid a = (r0, a)` for some specific `r0` of type `R`. The choice can't depend on the value of `a`, because `mid` needs to work for `a`s of _any_ type. Then the MapNable Laws will entail:
+
+ 1. (r0,id) m$ (r,x) == (r,x)
+ 2. (r0,f x) == (r0,f) m$ (r0,x)
+ 3. (r0,(○)) m$ (r'',f) m$ (r',g) m$ (r,x) == (r'',f) m$ ((r',g) m$ (r,x))
+ 4. (r'',f) m$ (r0,x) == (r0,($x)) m$ (r'',f)
+ 5. (r0,f) m$ (r,x) == (r,($x)) m$ (r0,f)
+
+Now we are not going to be able to write a `m$` function that inspects the second element of its left-hand operand to check if it's the `id` function; the identity of functions is not decidable. So the only way to satisfy Law 1 will be to have the first element of the result (`r`) be taken from the first element of the right-hand operand in _all_ the cases when the first element of the left-hand operand is `r0`. But then that means that the result of the lhs of Law 5 will also have a first element of `r`; so, turning now to the rhs of Law 5, we see that `m$` must use the first element of its _left_-hand operand (here again `r`) at least in those cases when the first element of its right-hand operand is `r0`. If our `R` type has a natural *monoid* structure, we could just let `r0` be the monoid's identity, and have `m$` combine other `R`s using the monoid's operation. Alternatively, if the `R` type is one that we can safely apply the predicate `(r0==)` to, then we could define `m$` something like this:
+
+ let (m$) (r1,f) (r2,x) = ((if r0==r1 then r2 else if r0==r2 then r1 else ...), ...)
+
+But for some types neither of these will be the case. For function types, as we already mentioned, `==` is not decidable. If the functions have suitable types, they do form a monoid with `○` as the operation and `id` as the identity; but many function types won't be such that arbitrary functions of that type are composable. So when `R` is the type of functions from `int`s to `bool`s, for example, we won't have any way to write a `m$` that satisfies the constraints stated above.
+
+For the third failure, that is examples of MapNables that aren't Monads, we'll just state that lists where the `map2` operation is taken to be zipping rather than taking the Cartesian product (what in Haskell are called `ZipList`s), these are claimed to exemplify that failure. But we aren't now in a position to demonstrate that to you.
+
+
+## Further Reading ##
+
+As we mentioned above, the notions of Monads have their origin in Category Theory, where they are mostly specified in terms of (what we call) `mid` and `join`. For advanced study, here are some further links on the relation between monads as we're working with them and monads as they appear in Category Theory:
+[1](http://en.wikipedia.org/wiki/Outline_of_category_theory)
+[2](http://lambda1.jimpryor.net/advanced_topics/monads_in_category_theory/)
+[3](http://en.wikibooks.org/wiki/Haskell/Category_theory)
+[4](https://wiki.haskell.org/Category_theory), where you should follow the further links discussing Functors, Natural Transformations, and Monads.
+
+Here are some papers that introduced Monads into functional programming:
+
+* Eugenio Moggi, Notions of Computation and Monads: Information and Computation 93 (1) 1991. This paper is available online, but would be very difficult reading for members of this seminar, so we won't link to it. <!-- http://www.disi.unige.it/person/MoggiE/ftp/ic91.pdf --> However, the next two papers should be accessible.
+
+* [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. -->
+
+* [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. -->
+
+Here is some other reading: