Isolating Side Effects with Monads: A brief tour of the Reader / Writer & State Monads
This talk largely follows on from Katie's talk last month, examining three monads that are extremely useful for modelling traditionally imperative things in purely functional code.
We'll explore a very imperative piece of scala code and refactor it gradually around the reader, writer and state monads until we're left with a purely functional piece of code. During this exploration we'll also stumble on the fact that nested monads aren't very fun and show how monad transformers make our lives easier. Finally by examining some of the helpful machinery that can be written abstractly around the monad typeclass (rather than each and every flatmappable thing), we'll hopefully convince ourselves again that this weird and wonderful monad concept is a Good Thing™.
This talk will be aimed at a beginner level, so don't fret if you have never heard of these things or programmed in Scala before. This talk will be done at a deliberately slow pace to let it all sink in.
Many introductions to functional programming discuss the fold functions on lists. There is fold-left and fold-right, followed by attempts to develop an intuition on how to understand, internalise, then exploit these functions as necessary. Such attempts use concepts like "folding from the right or left", but this can often lead to even more confusion, because it is not entirely accurate.
In this talk, I will explain to you how list folds work using an explanation that is very easy to understand, but most importantly, without sacrificing accuracy. After I have convinced you about how to explain list folds to yourself, I will then further convince you that you should always use this explanation on others. You should then be able to deploy these functions as necessary on your own by appealing to this easy, accurate explanation.
As a minimum, you will be expected to have some simple introduction to the existence of list folding. If you know these functions exist, but you are totally confused about what they mean, then this talk is for you.
Laws and Equations and Coq! Oh, My! (or More Equational Reasoning) - David Laing
Haskell isn't able to determine whether Monoid and Functor instances satisfy the appropriate laws, but that doesn't mean it can't be done. This talk will walk step by step through the process of using equational reasoning to prove that the Monoid and Functor laws hold for their list instances. We'll then look at how to verify these laws using Coq, and at the Haskell code extracted from the Coq proof.
Dave wrote code for a few years, did a PhD in theoretical computer science, then continued to write code. Most recently he's been feeding his bank account by coding in C++ and feeding his mind by coding in Haskell.
When writing Haskell programs, we tend to use lots of polymorphic types. That's good! We can reuse those pieces, thanks to the types. But when implementing polymorphic functions, it can sometimes be difficult to see how things fit together, especially if we don't have a systematic approach.
At a recent Haskell course taught by members of this group, I discovered such an approach, which we call "hole driven development". I'll demonstrate the technique, including some tricks to get help from the compiler. I'll also preview an exciting new language feature which will hit the Haskell platform soon.