Introduction to Laws

Editor's Notes

• #2: Alternative title: Law & Order: Refactoring Crime Unit.
• #4: We need to remember to come back to laws.
• #6: Understanding Laws: Explain a few fundamental laws, then learn some typeclasses by focussing on their laws.
• #8: Familiarity from School Example of the use of a law. What’s it name? Note some similarities to programming: * Expressions on the left hand side and right hand side * Substitutability
• #9: Generalised to Addition Made the integers parameters Only ‘+’ is left as an operator
• #10: Generalised statement about any binary operation Binary - takes 2 arguments, eg. plus, times, etc.
• #11: We’ve now seen an example of a law, and where it came from We’ve seen an example of a function satisfying a law
• #12: We can leverage the law in programming: doing the operations in order that is most clear to readers, or fastest. If you’re writing a function, and you’re calling it integer addition, you need to satisfy the law. Or you will be taken down. The law is just like programming with contracts.
• #13: Explain the signature: function name, syntax/puncutation, arguments, return type. Where does the law fit into this? It doesn’t.
• #14: Technique for hand verification is equational reasoning, see that later Occasionally verified with QuickCheck, but it’s hard to satisfy yourself. QuickCheck requires a good Arbitrary. Easy to get wrong.
• #15: Statements of equivalence? Refactoring! Substituting methods for expressions, expressions for expressions, etc. Contracts in programming (not null parameters, etc.) are very useful. When a new law is required, the decision is made by the community. The most useful law is generally obvious.
• #17: Tackle in 2 parts. First we’ll look at some laws that may be familiar. The ones from abstract algebra, that apply to things like addition and multiplication. Second part we’ll look at some typeclasses, and the laws they require. Generalising part 1.
• #18: Someone tell me a way of remembering this
• #19: Step from list to the operation Sum the list in any pairing of subsequent parts
• #20: Flipping. String addition, not satisfied. Prefix becomes suffix. + in java: commutative for integers, not commutative for strings. Should + be overloaded like this?
• #21: Start with our application of the associative law. Commutative law says we can swap all the parts Now, if we parallelise this operation as summing into an accumulator, it now longer matters which parts of our computation come out first. Because Laws! How useful!
• #22: This is interesting, because there are now 2 parts. The identity value, and a binary operation. There’s a relationship here between two things. TODO: show a + 0, a * 1, matrix * I
• #23: Now to typeclasses, which is where things get real. Now I want to build on what we’ve just seen. Particularly, Associativity (changing the parentheses), and Identity.
• #24: Explain the code. This is an interface. Note there’s something missing. We have 2 functions we need to implement, but nothing about how they should be implemented yet. Also, there’s nothing that ties these 2 functions together. At this point we know where this is going. Anyone want to take a stab?
• #25: This is interesting, because there are now 2 parts. The identity value, and a binary operation. There’s a relationship here between two things. Relationship is what is important. Jump back.
• #26: Laws tie these functions together. Each could be implemented independently.
• #27: This is interesting, because there are now 2 parts. The identity value, and a binary operation. There’s a relationship here between two things. Relationship is what is important. Jump back.
• #28: A step up from what we’re doing. Functor.
• #29: Explain the code again. What is a functor? something you can map over. Anything with a map function. Transforming contents of a containing is one of the most obvious implementations.
• #30: Explain each law on its own. Space is function application. Show that they are statements of equivalence. Meaning: * does not change the structure * changes a value without changing its context
• #31: Duplicates the first functor value. If we do fmap with identity, we’ll end up with an extra value out the front. This is not the same as just doing identity. We’ll see how to implement a real one soon
• #32: Laws tell us what a functor really is.
• #34: understanding Monoid: Identity means nothing without an Mappend. Defined in terms of mappend. understanding fmap: preserving the structure. We can use that to help us define instances. Substitution: Tooling can take advantage of this.
• #38: This is not a law. This is a rewrite statement in GHC. Specific to lists, however it could be (because of laws) changed to fmap. Then it looks very similar to the statement of the fmap for composition.
• #40: Verification is sometimes hard.
• #41: Splitting apart Monoid and Monad. What can we say about these functions? What laws can we write? Nothing. They both require other functions to define themselves *meaningfully*.
• #42: Verification is sometimes hard.
• #43: A bijection: Everything in X maps to EXACTLY one item in Y. Every X is covered. Every Y is covered. There must be an inverse.
• #44: Every Int must map to a unique String, *every* string must map to a unique integer. Otherwise this is not a bijection. Trivial to prove its not the case.
• #45: Every Int must map to a unique String, *every* string must map to a unique integer. Otherwise this is not a bijection. Trivial to prove its not the case.
• #47: Parallelism, optimisations
• #48: Lens is amazing. Look for his talk at NY Haskell. Pipes is a laws-driven implementation of iteratees.