Skip to content
0:00 / 0:00

#monoids#monads#categorytheory

Laws! - George Wilson - Compose Melbourne 2018

Compose Conference

2.9K subscribers • 31 videos on Hallway

YouTube
  • Recommended by 2 people: 1 in engineering communities and 1 curated list.
  • Presented by George Wilson

Intermediate. Assumes working knowledge.

1.8K views8 years ago2 recommendations

Programming languagesSoftware designFunctional programmingHaskellDesign patterns

George Wilson explains why algebraic laws are crucial for functional programming abstractions like Monoids and Monads, showing the benefits they provide.

Laws! composeconference.org/2018-melbourne/speakers/#george_wilson Laws, laws, laws. It seems as though whenever we learn about a new abstraction in functional programming, we hear about its associated laws. Laws come up when we learn about type classes like Functors, Monoids, Monads, and more! Usually laws are mentioned and swiftly brushed past as we move on to examples and applications of whatever structure we're learning about. But not today. In this talk, we'll look more closely at laws themselves. Why should our abstractions have laws? We'll answer this question both by seeing powers we gain by having laws, and by seeing tragedies that can befall us without laws. We will look at examples of the utility of associativity and identity in working with Monoids. Concretely, appending a collection of lists going from left to right is O(n^2), but associativity gives us the power to append them all in O(n) - while knowing we'll get the same answer. More abstractly, we'll see that without the laws, the number of useful functions we can write in terms of Monoid's interface is severely diminished. Similar arguments, both in the abstract and the concrete, will be made for the Functor laws of composition and identity, and the Monad laws. The common theme is that laws let us get the most out of our abstractions. This is further highlighted by examining Data.Default - a dreaded lawless type class. Finally, we will make recommendations about how to verify whether the laws pass when one makes an instance of an abstraction, using the testing libraries QuickCheck and checkers. Goals An attendee should learn why giving laws to our abstractions helps us work with and understand them. Attendees should leave the talk better equipped to exploit the advantages of these laws and with knowledge of how to test whether they hold. About George Wilson George Wilson is an enthusiastic functional programmer from Brisbane, Australia. He works on open source Haskell projects at the Queensland Functional Programming Lab inside Data61. George is a member of the Haskell.org committee, and a Hackage Trustee.

Why it's here

2 people recommend this

What people say. Recommended for understanding the practical utility of algebraic laws and category theory concepts in Haskell.

u/_jackdk_in r/haskell • Recommends

On “How has Category Theory improved your Haskell code?”

Caveat: I am not a CT wizard, but I know a few of the definitions and have done a bit of study. CT seems useful to me in a few ways: 1\. Diagrammatic reasoning. It is often quite powerful to build up a diagram and say "because the diagram commutes, this fast path from type `A` to type `B` is going to give me the same answer as this other slow path". Stealing an example from George Wilson — Laws!: left-associated list appends are _O(n^2 )_. But if you convert to `DList`, do all your appends, then convert back to regular lists, all of those arrows are _O(n)_ or faster. That this is safe comes from the fact that there are monoid homomorphisms between `a` and `DList a`, and you draw a nice…

programming-talkscurated list on GitHubRecommends

Under “Haskell”

Laws! 00:28:03 by **George Wilson** (2018)

u/gelisamin r/haskell • Mentions

On “Quick question about overloading for different sub-data types”

> And not in the light of me being a beginner? Haskell does have a mechanism, called "type classes", which allows you to write a function `eat` which behaves differently when given a value of one type vs another type (but they really do have to be different types; in your example, `Apple`, `Orange` and `Fruit` are all the same type). However, beginners are often misusing type classes, because other languages have things called "classes" which are used for a completely different purpose. In particular, in Haskell, using type classes just to get overloading is sometimes frowned upon, so learning type classes in that context does seem like a bad start. If you do want to learn about type class…