Simon Peyton Jones returns to Haskell eXchange to announce the launch of the Haskell Foundation, an independent, non-profit organisation dedicated to broadening the adoption of Haskell, by supporting its ecosystem of tools, libraries, education, and research. Do join us to hear about the plans so far, and to help shape what the Foundation becomes.

There will be an extended Q&A as part of the session.

To ensure as many people as possible hear about this important announcement, this Opening Keynote will also be live-streamed on YouTube. Watch the stream for free here.

Winter is a Haskell port of the reference implementation of WebAssembly, and I wanted to use it in one of my projects. It runs small examples just fine, but once they get a bit larger, it was just too slow. So I pulled out the profiler and went hunting for low-hanging fruit, and also less low-hanging fruit, plucking 7 in total:

• Using Vectors instead of Lists
• SPECIALIZE
• Difference lists
• Export lists
• Eta-Expanding ReaderT
• Simpler code
• …and a zipper.

In this talk I will show how I identified the bottle necks, how I solved them, and how big the gain was. All of this is real – I will be retracing the steps I took while solving a real problem I was facing.

Maybe you've got yourself a Kubernetes cluster for your Haskell web servers, are considering getting yourself some Haskell for your Kubernetes cluster, or already have a Kubernetes cluster smashed by shoddy Haskell deployments which were never performance tested?

I would like to take you on an adventure with Haskell on a Minikube to show you some basic facts about interactions among Docker, Kubernetes and Haskell runtimes. I will introduce you to cheap and cheerful performance testing with the apib tool, and show you places you can go by applying and not applying Kubernetes and Haskell best performance practices.

Have you ever wondered whatever Haskell is faster than Node.js? Did you lose sleep over choosing threaded or non-threaded runtime, determining how many threads to give to your Haskell runtime? Would you believe that Docker makes your app faster, occasionally? Does setting up Half a CPU requests and limits on Kubernetes remind you of the Judgment of Solomon?

Let us smash out of doubts pounding Haskell on a Minikube.

This talk will discuss how to apply the upcoming GHC language extension LinearTypes to manage references to values in a foreign language.

Our case study will be inline-java, a library that allows you to embed Java code in Haskell modules and integrates the JVM and the Haskell runtimes. Managing references to objects in the Java heap has remained an error-prone task. The programmer is responsible for deleting these references in a timely fashion. Delete too soon, and we get use-after-free errors. Delete too late, and we get intermittent OutOfMemory errors from the JVM. Forget to delete a few of them, and the memory of your application will grow steadily over time without an obvious cause.

We will show how linear types involve the compiler in checking that a program does a timely disposal of references to foreign values, effectively eliminating the most common bugs related to it.

After exposing a background of generating API bindings for the multicloud services, we use this case study to present our rules of thumb for agile data analytics development.

Michał presents examples with Haskell code and shows how best practices of functional programming solve practical problems of data analytics case-by-case. All cases are naturally motivated and embedded in this case study, but are illustrated with a short Haskell code sample.

The material is aimed at intermediate and expert Haskellers that want to reuse our techniques for other data analytics pipelines, or beginners who want to quickly learn the best monad to use when analysing thousands and millions of records on the input.

View the slides from this talk here:

Haskell is known for its clunky record syntax and common knowledge is that "lenses and prisms help", but the lens library (the biggest player on the field) is notoriously hard to grasp (even for experienced Haskell developers). Presenting an alternative solution that is easier to work with (and has been successfully used in production) is key to encouraging newcomers to keep exploring the language, but making lives easier for existing Haskell developers.

The talk will focus on the optics library (https://github.com/well-typed/optics).

Andrzej Rybczak will discuss:

how it separates the implementation details from the user-facing API,

how its API differs from the one provided by the lens library (yet matches its power) and

why it matters for Haskell developers who are new to the concept of optics.

He'll also discuss how optics solves the infamous Haskell record problem in a satisfactory way (with the help of OverloadedLabels extension) and why the approach doesn't compete with the incoming RecordDotSyntax extension, but rather complements it.

When GHC processes a Haskell program, it must perform type inference. This process includes both determining the types for definitions that lack type signatures and figuring out how polymorphic functions should be specialized at a particular usage site. To figure it all out, GHC looks at the Haskell program, generating constraints like "the type of x must match the expected argument type of f" and "the type of y must have a Show instance". Then, GHC must find a choice of types that satisfy all the constraints.

After a brief introduction to this generate-constraints-and-solve approach, this example-driven talk focuses on the constraint solver, explaining how it works, and showcases two large simplifications currently under way. You'll get a glimpse of how GHC works under the hood, learn why it's so hard to get good error messages, and get a sense for the kinds of problems that exist in GHC's type checker. This talk is also essential background information for anyone interested in writing type-checker plugins, though plugins will not be a focus of the talk. The audience should be able to understand simple Haskell programs; no advanced Haskell needed.

The idea for this talk came to me when I was looking for a Haskell library for JWT. I wasn't completely satisfied with interfaces like HashMap Text Value, so I decided to write something myself. It eventually took the form of libjwt-typed library.

It turned out that I had to explore many things that I wanted to share with other Haskell enthusiasts:

• type families
• “open product" types
• GHC rewrite rules
• FFI
• DataKinds
• generics

I think that this material can serve well as a cheat-sheet. In the course of this talk, I'll try to present how these (sometimes not widely known) techniques can be applied to solve well-defined domain-modelling problems. But more importantly, I'll try to convince the audience that seemingly “complicated" Haskell is not so difficult at all, and can bring tangible benefits. Despite what SimpleHaskell advocates say: the library turns out to be many times faster than contenders, while giving the user a more enjoyable, less error-prone interface to work with.

Rhythmr is an interactive system, implemented in Haskell, for creating ear-pleasing rhythm loops from randomly-acquired audio files. The user iterates through an unending stream of randomly combined music loops, swiping left or right on each one to indicate whether they like it or not. Rhythmr derives a model of which combinations sound good based on user input, and from that, produces a complete song by inserting the chosen combinations into a predefined score.

I’m a recent Haskell convert, and Rhythmr is the first useful application I’ve created with it. It required my learning a lot of Haskell skills: audio, graphics, profiling, optimization, user interactivity, and more.

Haskell was crucial to the success of this project, for it allows efficient construction of reliable software, and pure state handling made implementing features like ‘undo’ very easy. I was able to prototype many variations of the algorithm and interface in order to produce a usable tool.

Shpadoinkle is a programming model for UI development, oriented around simplicity, performance, and ergonomics. We will build a small application in Shpadoinkle from scratch. This will be an application just big enough to demonstrate how simple concepts compose gracefully into larger structures. We will discuss how to formalize separation of concerns and define what it means to be a UI component.

Haskell is known for its strong static typing but there are even stronger typing disciplines! Refinement types are types 'annotated' with 'predicates'. Dependent types allow terms to appear in types. Both of these disciplines allow the programmer to be more specific. A classic example is defining a type of lists of length 'n'. Both of these disciplines allow the programmer to prove that some function is valid on all possible inputs, a much stronger proof of correctness than a battery of tests. How are these two disciplines different? How do they work? How can you experiment with them? I'll answer these questions and demonstrate with examples in A Brief Introduction to Refinement Types and Dependent Types.

You can also view the slides from this talk here.

This talk discusses how to implement proper property testing in Haskell. It moves way beyond the classic toy examples and examined real-world scenarios. It takes a deep-dive into how to make property tests interact with web services or database systems. It also explains how to use custom generators and testing combinators. Other topics discussed are as follows:

• Testing with Databases
• Testing with Services
• Writing Custom Generators
• Using Testing Combinators

Most languages are strict. Haskell is very much the odd one out there. So, it is not surprising that programmers in strict language sneer at Haskell's laziness, nor that Haskell programmers feel compelled to defend this choice. But because of the adversarial nature of this debate, it ends up with cheap slogans such as “strict languages are more efficient” or “lazy languages compose better”.

This doesn't tend to be very enlightening. After all, the most likely answer (if maybe unsatisfactory) is: it depends. The choice between strictness and laziness is, at the end of the day, as most things in engineering, a trade-off. And to make an informed choice between these two technologies, we need to know what the costs and benefits of each are.

My goal is to provide tools to make such an informed decision by sharing, based on my experience as a programmer in both lazy languages and strict languages, the strengths and weaknesses of both paradigms. If you’re looking for me to tell you which is best, you will be disappointed. On the plus side, there will definitely be some production horror stories.

This talk should be of interest to Haskell engineers of all levels, people who are only learning Haskell, and those who would like to improve as a mentor or educator either in your company or generally.

In the typed functional programming communities, there is much talk about "reasoning with types". But rarely is this elaborated into something concrete. Just how can we extract tangible information from types beyond playing mere type tetris? The secret sauce is called parametricity, first described by John C. Reynolds, and later applied to Haskell by Philip Wadler in his influential paper "Theorems for free!".

Smallpt is a tiny ray-tracer in C that's been ported to many languages due to its size and simplicity. Unfortunately, the Haskell version is slow: 5-8x slowdown on a naive translation. In this talk, we are going to first port it to Haskell, and then make it fast, by using GHC pragmas, inspecting Core, reading GHC's profiling information, and reasoning about Haskell's execution model.

Attendees will learn how to tune a program that's neither too small (a micro-benchmark) nor too large (a monolith): This application is small enough to be digested, while large enough to exhibit "interesting" performance optimisations. It's a good case study to get one’s feet wet into Haskell optimisation.