Automatic differentiation is all the rage these days, largely because it is a key enabler for machine learning. But reverse-mode AD (the important kind) is a bit mind bending, and becomes much more so if you want reverse-mode AD for higher order programs (i.e. the kind we love).

In this talk I’ll explain what AD is, and how we can do it for higher order programs, using a series of simple steps that take us a simple-and-obviously-correct version to a weird-but-very-efficient one. At the end of the road we’ll find the Kmett/Pearlmuttter/Siskind ‘ad’ library in Hackage… but I hope we’ll see it with new eyes.

We are honoured to welcome back Simon Peyton Jones to the Haskell eXchange.

Since the very first Haskell eXchange in 2012, we've been lucky to have Simon join us each year to share his unique perspective on everything from front end features to join points , Linear Types, and pattern matching — not to mention last year's very special announcement of the Haskell Foundation.

Check out all of Simon's previous Haskell eXchange talks here.

In this talk Aravind will share his team's experience at Juspay, migrating a 65K line nodejs codebase to Haskell. He will take you through the entire journey of migration, parts where Haskell shines and also the not so good parts of Haskell. He will talk about :

1) Haskell as a preferred language choice 2) How we migrated 65K Lines of Code in just three months 3) Haskell Type System — A Super Power 4) Wins we got post migration — Extremely performant code, 100% more throughput per core 5) And just a few things we wish were better about Haskell

This talk will give you insights and an unbiased view into what it takes to adopt Haskell at large scale, parts where Haskell is a super power and things to watch out for.

GHC's constraint solver is a notoriously difficult beast to understand, and there aren't many tools available to help us understand the process that GHC goes through while type-checking.

In this talk, we will give an overview of how GHC generates constraints in the process of type-checking, and how it goes about categorising them and solving them. In particular, we will cover:

1. Wanted and Given constraints,
2. GHC's classification of predicates,
3. typeclass instance resolution,
4. implication constraints and the recursive nature of constraint solving,
5. how type-checking plugins fit in with this story.

The idea for the talk came from a series of performance investigations in which we tried to nail a bug that was causing unusually long pauses on our production machines. What was even more interesting was that the slowdown seemed to have quadratic characteristics, but all the GCs algorithms are certainly linear? It turns out that there are corner cases where this is not true. In fact, we have proposed a (accepted) bug report to GHC outlining this particular problem: https://gitlab.haskell.org/ghc/ghc/-/issues/19897

While these findings are interesting on its own, they would make a rather hermetic presentation. So instead of presenting the dry facts, the talk would turn towards topics that I believe to be valuable independent of a particular case: how to profile a misbehaving program and collect conclusive results pointing to the real cause; overview of existing GHC memory management tactics and data structures; general structures that can be used in memory management (trees, skip-lists) and their characteristics; how to hack on GHC to implement a new idea; how to use a hacked GHC.

There are three main sources of of quadratic blow-up in the ghc core code generated during compilation. First, we cannot refer to or update a field of records without mentioning all the fields of that record, where it should be noted that type class dictionaries are also records. Second, lack of type level sharing results in a lot of duplication when using data types with constructors that reflect some kind of inductive structure. Third, type family reduction results in large type equality coercions.

In this talk we will take a closer look at each of these problems. We will see how the large-records library manages to circumvent all of these problems, but we will also discuss the principles involved in the hope that you can apply those in your own code. Although it would be good to tackle these problems at a more fundamental level, this talk focuses on how to deal with these problems with current-day ghc, not a hypothetical future one.

What is it like to bring Haskell to a large enterprise with an established culture? There are success stories for specialized teams, but what about the mainstream? We've been working in the trenches alongside enterprise developers doing Haskell for more than 3 years and have lots to report. This talk explores what it is like to use Haskell in an environment where the understanding and software engineering experience of developers is very mixed. Ranging from the Haskell language and the ecosystem around it, to how it has impacted the systems and people working with it, we will examine the journey from an introduction that took us into stormy seas and the vision of clear skies ahead.

HLS is a popular Haskell IDE: fast, feature-rich, extensible, easy to install and ubiquitous. But what happens when you try to use it in a very large enterprise codebase?

To understand the performance characteristics, we will deep dive into the ghcide build graph and execution model to characterise the amount of work done per keystroke. We will learn that currently the work is proportional to the number of import declarations and that this doesn't scale well. To address this issue we extend HLS to track the build nodes changed since last build and obtain a reactive build graph where the amount of work is proportional only to the number of nodes changed and their reverse dependency closure.

HLS is an IDE engine built on top of a build system. The programming model is fantastic, and this talk shows that it also has an efficient execution model. Moreover, the talk will hopefully shed some light on the internals and serve as a resource for current and future HLS contributors.

Program synthesis is a promising approach to automating low-level aspects of programming by generating code from high-level declarative specifications. But what form should these specifications take? In this talk I will advocate for using types as input to program synthesis. Types are widely adopted by programmers, they can vary in expressiveness and capture both functional and non-functional properties, and finally, type checking is often fully automatic and compositional, which helps the synthesizer find the right program.

I will describe two type-driven program synthesizers we developed. The first one is Synquid, a synthesizer for recursive functional programs that uses expressive refinement types as a specification mechanism. The second one is Hoogle+, which relies on more mainstream Haskell types and generates code snippets by composing functions from Haskell libraries.

The first GHC version with the LinearTypes language extension is released early this year. This extension allows using linear arrows, where a function can specify how many times it uses its parameter. This seemingly minor ability opens up the door to many new abstractions; including, but not limited to, safe resource handling, pure mutable collections, and even the ability to manipulate values that are not managed by the garbage collector. linear-base, the standard library for linearly-typed Haskell programs, provides a fair number of utilities making -XLinearTypes convenient and also implements some of these new abstractions.

There are many in-depth articles and talks about specific uses of linear-base, but this talk will provide a broader overview of what is possible with linear-base now; walking through the different areas of the library pointing out their practical use cases; but also what they are lacking and what is being discussed. I hope it will encourage more people to experiment with linear-base, take part in discussions and become contributors.

Streamly provides declarative combinators to express loops as a pipeline composed of modular building blocks. Each pipeline stage encapsulates a transformation over the data.

Streamly makes it possible to compose concurrent programs declaratively. Data processing pipelines can be composed of concurrent actions and can run concurrently. Streamly unifies many functional abstractions; a small set of high-level combinators can express a wide variety of programming problems.

Traditionally, you can write idiomatic programs that do not perform so well or high-performance programs that are not so idiomatic. Streamly provides both.

This talk aims to introduce the library to a wider audience. We will go over the motivation for the library, how it is different from existing solutions, the abstractions it provides, key innovations, performance characteristics, and how to express some practical problems using the library.

See more details at the streamly homepage.

Existing effect systems in Haskell all use one of two approaches: Free monad or effect typeclasses. As Alexis King pointed out in her talk in ZuriHac 2020, these two approaches are both unfriendly to compiler optimization because they all generalize too much, making neither effectful operations nor bind operations inlinable.

A design pattern comes to rescue, the “phantom constraint pattern.” It works with effect typeclasses, in particular the ReaderT pattern. It allows users to write effectful code on a concrete monad, which is much more friendly to the optimizer than a free/polymorphic monad, while at the same time having the ability to control the use of effects via specific redundant constraints that contain no information.

I will also talk about a work-in-progress effects library of mine, availability, that uses the said design pattern. I will give a comparison of its usage against other libraries and its design concerns.

Nix is a package manager popular in the Haskell world, sharing many ideas with Haskell. In this talk, Krzysztof Gogolewski will explain Nix using Haskell as a basis. I assume basic knowledge of Haskell, but no knowledge of Nix.

What is the novelty of Nix?

Learning Nix and NixOS involves multiple jumps - the store, expressions, derivations, dependencies, packages, system configuration... Furthermore, as with any engineering project there's machinery that accounts for the messy reality.

The talk is inspired by "Build Systems a la Carte" and "Nix pills", but they are not prerequisites. This will not be a tutorial on accomplishing specific tasks with Nix, but it should give enough background to prepare attendees for a deeper dive.

The goal of this talk is to explain delayed arrays, that are available in massiv library, as well as their roles in fusion and parallelization of operations applied to multi-dimensional arrays.

Immutable arrays in Haskell come with great safety properties and provide opportunities for a variety of optimizations. However, without fusion most operations on arrays do not compose efficiently due to intermediate allocations. Delayed arrays provide us with a reliable fusion framework, which is fully controlled by the user and guided by the type checker.

Many operations on arrays are massively parallel, however the common Haskell technique of evaluating with pseq and relying on GHC's spark pool is not applicable to unboxed arrays because it relies on laziness. Combination of a custom scheduler and delayed arrays can help us with a solution, so we can benefit from multi-core parallelization.

In this talk, Luc will show how to create a language by making use of LLVM and Haskell. At the start, an introduction will be given on LLVM and the corresponding Haskell bindings.

Afterwards, Luc will explain how techniques such as combinators and partial evaluation can be used to create performant functions optimized by LLVM. At the end, everything will be brought together and the result will be a small language that compiles all the way down to assembly.

Provided that data fits entirely within memory we can process data in an elegant way using classic Haskell techniques. Once we have more data than can fit in memory however we are often forced to abandon elegance to deal with mutable disk state in IO. While streaming style applications can often maintain an elegant pure core, it is particularly difficult to do so for transaction processing (OLTP) style applications which typically need random access to their data sets. The usual approach to building these applications involve using SQL or key-value databases and intermingling program logic with actions to fetch and change stored data.

This talk explores an approach for OLTP style applications to scale to data sets bigger than fit in memory, while preserving a functional approach and the usual associated advantages. The approach uses ordinary pure functions that work over in-memory data structures, but nevertheless keeps the bulk of data on disk. The talk will explain the concepts and report on initial experience of applying the ideas in an existing commercial application.

Specifications languages have demonstrated themselves as an effective tool for designing and reasoning about complex software systems by capturing a high-level description of the system behavior in temporal logic. Declarative specifications of the intent of a system also serve models that can be checked in a fully automatic way, giving engineers formal guarantees on the correctness of their designs according to their specifications.

In this talk, I will give an overview of Spectacle, a Haskell EDSL for writing formal specifications in the temporal logic of actions, and how specifications written in Spectacle can mechanically verify real-world Haskell programs.

Many programming languages have a start with an academic foundation, but few languages carry such a deep sense of academic identity as they cross over into adoption in the industry. Haskell seems so different from the rest.

SimSpace has been using Haskell at scale across nine teams, collectively maintaining over 400k lines of Haskell, developed over five years. We have a number of shared experiences and can speak to lessons learned over the years. This talk is an opportunity to share those experiences and give some helpful advice to others on a similar trajectory of using Haskell commercially.

There's such a rich and historic narrative coming from the academic side of Haskell. This talk seeks to complement that narrative with an industrial perspective.