The goal of the talk is to demonstrate non-trivial uses of QuickCheck for testing Haskell programs. Outside of papers and book chapters, most of the information on QuickCheck only covers very basic usage. This talk is about the more advanced uses of QuickCheck, including the use of QuickCheck with monadic code, as well as how QuickCheck can be used in the parallel development of code and specifications.

The talk will begin with a very brief overview of the usual basic level QuickCheck as described in Real World Haskell and various sources on the internet. This will introduce some tests involving sorting and searching. These tests will be iterated on to demonstrate the development of QuickCheck specifications, along with some of the more advanced features of QuickCheck and how to avoid some common errors.

The next part of the talk will develop a purely functional queue and show that it is correct via both an algebraic specification and a model-based specification. This should give a really good feel for how to develop useful specifications and what they typically end up looking like.

The final part of the talk will cover the use of QuickCheck with monadic code. As well as demonstrating the use of the monadic interface to QuickCheck, this will work through a few small examples to help build an intuition for the kinds and scopes of problems which QuickCheck can be applied to.

Extended versions of the example code, slides and links to the reference materials used will be available via github.

Monads, monad transformers and free monads are commonly used and understood, but the comonadic equivalents have received a lot less attention. The goal of this talk is to discuss comonads, comonad transformers, and cofree comonads.the different perspective they provide, and how they can be used as a better abstraction for some problems.

The first half of the talk will be building up the intuition for what comonads and comonad transformers are for and how you can use them.

This will be done by comparing and contrasting various comonadic entities with their monadic equivalents, poking around with some concrete instances, and demonstrating some examples of comonads and comonad transformers in use.

The second half of the talk will be about cofree comonads, how they relate to free monads, and how we can use them together to do exciting things.

We’ll start with a quick recap of free monads, which we’ll use to develop a little language which will be the basis for our running example.From this we’ll develop a corresponding cofree comonad while explaining the intuition behind them, after which we’ll show how they can be made to work together.

We’ll end with a demonstration of how this is useful, and a whirlwind tour of some of the opportunities this opens up.

Languages in the ML family are great for writing domain-specific languages (DSL)s. We can use ideas from programming language theory (PLT) to make our DSLs more powerful, and we can use tools from the Haskell ecosystem to make our implementation easier to write, test, maintain and change.

This will be a lightning tour of how to build up a DSL that will get progressively more advanced throughout the talk. We’ll be exploring ways to keep the results testable (via QuickCheck) and composable along the way.

The first thing we’ll look at is operational semantics. We’ll specify the semantics of our DSL, implement the semantic rules in Haskell, and use that to derive an evaluator for our DSL. This in turns leads to a discussion of type systems. Some DSL programs can get stuck during evaluation, and type system can be used to check that a DSL program won’t get stuck.

Having both the semantic and type system specified also provides some opportunities for testing, and we can bias our implementation in order to do this in a way that will boost our confidence in the resulting DSL.

The next piece of the puzzle we will look at s parsing and pretty printing the DSL. Most importantly, we’ll cover the use of trifecta for parsing. This provides support for very good error messages, both in the parsing stage and in the type checking stage.

The last thing we’ll look at is lambda calculus, and how to embed lambda calculus into our DSL. This is a big step forward since it allows users of the DSL to abstract and reuse fragments of DSL programs. The implementation will be greatly assisted by the use of the bound library.

The remainder of the talk will be discussing various extensions and improvements that are either very useful or quite exciting.

The material will eventually appear in much more detail on https://dlaing.org. Most of the PLT material is covered in Pierce’s “Types and Programming Languages” and Harper’s “Practical Foundations of Programming Languages”.

Living in a statically typed world is great, but sometimes a part of your problem really does need to be modelled as something a bit more dynamic. Maybe something in your domain really should be modelled as a heterogenous collection. Maybe you just have a bunch of things you want to group together and work with via a common typeclass, but their types are all different. Maybe you're interfacing with a system that doesn't care about types. You might just want to feel the wind through your hair like when you were working with dynamically typed languages.

The dependent-map library (and friends) has you covered for all of these things. It gives you a heterogenous collection with great usability, where you use GADTs as the keys and have the "Functor Functor" pattern wrapped up in the mix for good measure.

This talk will start by looking at GADTs and the "Functor Functor" pattern to make sure everyone is on the same page, before spending some time getting to know the the details of DSum, DMap and friends. After that we'll spend some time looking at some of the additional things you can do using related libraries from the ecosystem, and then we'll spend the rest of the time looking at examples and applications.

There has been a lot of excitement about Functional Reactive Programming (FRP).

Most of it has been about distant relatives of the original idea, which are nowhere near as powerful or as useful.

The `reflex` library -- and the companion `reflex-dom` library -- were created in order to use FRP to do front-end development using Haskell.

This workshop will give you hands-on experience with these libraries.

The workshop will show attendees a new way to manage state and time-dependent logic, with significant benefits over the standard approaches when it comes to abstraction, composition and correctness.

It will also make the case that when these ideas are applied to front-end development, they lead to something beyond what is delivered by libraries like `react` and `redux`.