From a305ebfcf57b336d71c90664d504172fc1b91f6b Mon Sep 17 00:00:00 2001 From: Chris Date: Sat, 14 Mar 2015 14:30:24 -0400 Subject: [PATCH] moved files --- exercises/_assignment6.mdwn | 18 ++ topics/_week8_division_by_zero.mdwn | 169 ++++++++++++++ topics/_week8_monads_in_general.mdwn | 434 +++++++++++++++++++++++++++++++++++ 3 files changed, 621 insertions(+) create mode 100644 topics/_week8_division_by_zero.mdwn create mode 100644 topics/_week8_monads_in_general.mdwn diff --git a/exercises/_assignment6.mdwn b/exercises/_assignment6.mdwn index 9a3d04c0..86c398ff 100644 --- a/exercises/_assignment6.mdwn +++ b/exercises/_assignment6.mdwn @@ -112,3 +112,21 @@ our scorecard. On the simple-minded view, we would replace it with `w`. But that's not the right result, because `w` itself has been mapped onto 2. +## Baby monads + +(Depends on lecture notes for safe division by zero.) + +Write a function `lift'` that generalized the correspondence between + +and `add'`: that is, `lift'` takes any two-place operation on integers +and returns a version that takes arguments of type `int option` +instead, returning a result of `int option`. In other words, `lift'` +will have type: + + (int -> int -> int) -> (int option) -> (int option) -> (int option) + +so that `lift' (+) (Some 3) (Some 4)` will evalute to `Some 7`. +Don't worry about why you need to put `+` inside of parentheses. +You should make use of `bind'` in your definition of `lift'`: + + let bind' (u: int option) (f: int -> (int option)) = + match u with None -> None | Some x -> f x;; diff --git a/topics/_week8_division_by_zero.mdwn b/topics/_week8_division_by_zero.mdwn new file mode 100644 index 00000000..4bbf60b9 --- /dev/null +++ b/topics/_week8_division_by_zero.mdwn @@ -0,0 +1,169 @@ +[[!toc]] + + +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 = 
+# 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
+*)
+
+ +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: + +
+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 = 
+# add' (Some 12) (Some 4);;
+- : int option = Some 16
+# add' (div' (Some 12) (Some 0)) (Some 4);;
+- : int option = None
+*)
+
+ +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. + +
+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 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.] + + diff --git a/topics/_week8_monads_in_general.mdwn b/topics/_week8_monads_in_general.mdwn new file mode 100644 index 00000000..6dfbdeb8 --- /dev/null +++ b/topics/_week8_monads_in_general.mdwn @@ -0,0 +1,434 @@ +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: + +* 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 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 + 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`. 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 + 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` + 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`. + + 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. + (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. + + +A note on notation: Haskell uses the infix operator `>>=` to stand for +`bind`: wherever you see `u >>= f`, that means `bind u f`. +Wadler uses ⋆, but that hasn't been widely adopted (unfortunately). + +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 last expression. You can think of the +notation like this: take the singing box `u` and evaluate it (which +includes listening to the song). Take the int contained in the +singing box (the end result of evaluting `u`) and bind the variable +`x` to that int. So `x <- u` means "Sing me up an int, which I'll call +`x`". + +(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. (See our page on [[Translating between OCaml Scheme and Haskell]].) 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 -> '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 unit x = Some x;; + val unit : 'a -> 'a option = + # let ( >>= ) u f = match u with None -> None | Some x -> f x;; + val ( >>= ) : 'a option -> ('a -> 'b option) -> 'b option = + + 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 equivalently `( >>= ) u f` instead of `>>= u + f`. + + # unit 2;; + - : int option = Some 2 + # unit 2 >>= unit;; + - : int option = Some 2 + + Now, for a less trivial instance of a function from `int`s to `int option`s: + + # let divide x y = if 0 = y then None else Some (x/y);; + val divide : int -> int -> int option = + # 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 + + +* **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`. + + Wadler and others try to make this look nicer by phrasing it like this, + where U, V, and W are schematic for any expressions with the relevant monadic type: + + (U >>= fun x -> V) >>= fun y -> W == U >>= fun x -> (V >>= fun y -> W) + + 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): + + # 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 -> '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`. + +* **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, `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_topics/monads_in_category_theory). + +See also: + +* [Haskell wikibook on Monad Laws](http://www.haskell.org/haskellwiki/Monad_Laws). +* [Yet Another Haskell Tutorial on Monad Laws](http://en.wikibooks.org/wiki/Haskell/YAHT/Monads#Definition) +* [Haskell wikibook on Understanding Monads](http://en.wikibooks.org/wiki/Haskell/Understanding_monads) +* [Haskell wikibook on Advanced Monads](http://en.wikibooks.org/wiki/Haskell/Advanced_monads) +* [Haskell wikibook on do-notation](http://en.wikibooks.org/wiki/Haskell/do_Notation) +* [Yet Another Haskell Tutorial on do-notation](http://en.wikibooks.org/wiki/Haskell/YAHT/Monads#Do_Notation) + + +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) 1991. Would be very difficult reading for members of this seminar. However, the following 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. + + +* [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. + + + +There's a long list of monad tutorials on the [[Offsite Reading]] page. (Skimming the titles is somewhat amusing.) If you are confused by monads, make use of these resources. Read around until you find a tutorial pitched at a level that's helpful for you. + +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. + +Here are some of the other general monad operations. 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 = + +`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. + +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 (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 + +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 = 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 + + + +Monad outlook +------------- + +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. + +But first, we'll look at several linguistic applications for monads, based +on what's called the *Reader monad*. + +##[[Reader Monad for Variable Binding]]## + +##[[Reader Monad for Intensionality]]## + -- 2.11.0