-* Where Groenendijk, Stockhof and Veltman (GS&V) say "peg", that translates in our terminology into a new "reference cell" or "location" in a store.
+* Where Groenendijk, Stokhof and Veltman (GS&V) say "peg", that translates in our terminology into a new "reference cell" or "location" in a store.
* Where they represent pegs as natural numbers, that corresponds to our representing locations in a store by their indexes in the store.
-So far, we've defined monads as single-layered things. Though in the Groenendijk, Stokhoff, and Veltmann homework, we had to figure out how to combine Reader, State, and Set monads in an ad-hoc way. In practice, one often wants to combine the abilities of several monads. Corresponding to each monad like Reader, there's a corresponding ReaderT **monad transformer**. That takes an existing monad M and wraps a Reader monad box around it. The way these are defined parallels the way the single-layer versions are defined. For example, here's the Reader monad:
+So far, we've defined monads as single-layered things. Though in the Groenendijk, Stokhof, and Veltman homework, we had to figure out how to combine Reader, State, and Set monads in an ad-hoc way. In practice, one often wants to combine the abilities of several monads. Corresponding to each monad like Reader, there's a corresponding ReaderT **monad transformer**. That takes an existing monad M and wraps a Reader monad box around it. The way these are defined parallels the way the single-layer versions are defined. For example, here's the Reader monad:
(* monadic operations for the Reader monad *)
let { total = value; _ } = s0
in (value, { total = s0.total + 2; modifications = s0.modifications + 2};;
-But **the point of learning how to do this monadically** is that (1) monads show us how to embed more sophisticated programming techniques, such as imperative state and continuations, into frameworks that don't natively possess them (such as the set-theoretic metalanguage of Groenendijk, Stockhof and Veltman's paper); and (2) monads are delicious.
+But **the point of learning how to do this monadically** is that (1) monads show us how to embed more sophisticated programming techniques, such as imperative state and continuations, into frameworks that don't natively possess them (such as the set-theoretic metalanguage of Groenendijk, Stokhof and Veltman's paper); and (2) monads are delicious.
Keep in mind that the final result of a bind chain doesn't have to be the same type as the starting value:
[[!toc]]
-In class on November 22, we just reviewed mutation and aliasing, especially in relation to the Groenendijk, Stockhof and Veltman paper. Below, we bring in more material. This takes the form of making gradual improvements to the calculator we developed in [week7](/reader_monad_for_variable_binding). Part of what we do below is a review of the mutation techniques developed in [[Week9]]; but we also do other things we haven't discussed in class, like defining new complex functions in our calculator.
+In class on November 22, we just reviewed mutation and aliasing, especially in relation to the Groenendijk, Stokhof and Veltman paper. Below, we bring in more material. This takes the form of making gradual improvements to the calculator we developed in [week7](/reader_monad_for_variable_binding). Part of what we do below is a review of the mutation techniques developed in [[Week9]]; but we also do other things we haven't discussed in class, like defining new complex functions in our calculator.
##Original Calculator##
(* evaluate expr2 using original assignment function and new store *)
in eval expr2 g s''
-Note: Chris uses this kind of machinery on the third page of the Nov 22 handout. Except he implements `Let` the way we here implement `Change`. And he adds an implementation of `Alias` (see below). Some minor differences: on his handout (and following Groenendijk, Stockhof and Veltman), he uses `r` and `g` where we use `g` and `s` respectively. Also, he implements his `r` with a function from `char` to `int`, instead of a `(char * int) list`, as we do here. It should be obvious how to translate between these. His implementation requires that variables always already have an associated peg. So that when we call `Let(c, expr1, expr2)` for the first time with `c`, there's a peg whose value is to be updated. That's easier to ensure when you implement the assignment as a function than as a `(char * int) list`.
+Note: Chris uses this kind of machinery on the third page of the Nov 22 handout. Except he implements `Let` the way we here implement `Change`. And he adds an implementation of `Alias` (see below). Some minor differences: on his handout (and following Groenendijk, Stokhof and Veltman), he uses `r` and `g` where we use `g` and `s` respectively. Also, he implements his `r` with a function from `char` to `int`, instead of a `(char * int) list`, as we do here. It should be obvious how to translate between these. His implementation requires that variables always already have an associated peg. So that when we call `Let(c, expr1, expr2)` for the first time with `c`, there's a peg whose value is to be updated. That's easier to ensure when you implement the assignment as a function than as a `(char * int) list`.
##How to implement mutation with a State monad##