RequiredTypeArguments is a Haskell extension recently implemented in GHC as part of the Dependent Haskell initiative. In this talk, I will demonstrate how required type arguments enable better API design—including a type-safe printf implementation—and discuss the far-reaching implications of this extension for Haskell’s syntax.

While using the Haskell debugger has been possible via GHCi for the last two decades, the lack of a modern integration with IDEs, and incomplete, slow, or unimplemented features, has greatly hindered its adoption.

In this talk, we introduce our progress and plans to create a first-class debugger for Haskell. We’ve developed a standalone application using the GHC library that conforms to the Debug Adaptor Protocol (DAP), making Haskell debugging possible with all compatible IDEs. In the process, we’ve fixed long-standing performance and usability issues in the existing debugger implementation. Our goal is to bring debugging of Haskell programs to the same level as other language ecosystems. Finally, we’ll also reflect on the architectural limitations of the current debugger and outline our vision for the future of debugging in Haskell.

BangPatterns is a well understood Haskell extension and often used to great effect in order to improve performance. Beyond its current definition the idea of simply letting users write plus :: !Int -> !Int -> Int seems trivial at first glance as the concept seems to translate to such a type signature quite easily.

But what might a type signature like filter :: (!Int -> Bool) -> [Int] -> Bool tell us? And more importantly what can a compiler make out of it?

In this talk I will briefly cover the intuition of BangPatterns as they are today. How they change the meaning of programs but also how GHC can exploit these changes to make our programs faster.

From there we lift the idea one level up. How might things look if bangs were not just syntactic sugar but type modifiers instead? What would those modified types look like? But most importantly which benefits would this have for the expressiveness of Haskell itself, and how could both Haskell implementors and users make use of them to squeeze more performance out of their programs?

Excessive laziness can cause space leaks in Haskell programs. This talk gives theoretical and practical tools to catch these performance errors at compile-time. We claim that laziness can only lead to unbounded space leaks in stateful code. So, code should either be stateless or deep strict. The th-deepstrict library uses TemplateHaskell to assert that certain types are deep strict, ie, strict in all of their fields and the type of each field is itself deep strict recursively. By placing such assertions on the types that encode our program’s state, we can ensure that they do not lead to space leaks through laziness, while allowing the rest of our code to be as lazy as we desire.

The ability to compile multiple units within a single session was a key innovation for GHC API consumers like GHCi and HLS. Today, most Haskell projects involve multiple local packages that developers actively modify, so tooling must support this workflow seamlessly.

However, GHCi’s support for multiple home units remains limited. This significantly hampers productivity when working on multi-package projects. When developers start using multiple unit repl support, they expect the same experience as the old single-unit session.

In this talk, we present our approach to making GHCi fully compatible with multiple home units. Our goal is to deliver a seamless user experience: using GHCi with multiple home units should feel no different from working with a single unit. To achieve this, we are redesigning GHC’s interactive session management with multiple home units as the default model, treating single-unit sessions as a special case.

This unification eliminates fragile, infrequently used code paths, reduces test duplication and provides feature parity. Furthermore, GHCi’s built-in debugger will work transparently across unit boundaries, for example, allowing you to set breakpoints in a library component whilst debugging an executable.

Explicit Level Imports is an extension to GHC which allows a programmer to be more precise about which dependencies are needed for Template Haskell. In a module, each import is annotated with which level it will be needed at, some modules will be needed for use in splices, some in quotes and some in normal contexts.

This precision means it is straightforward for the compiler to work out what is exactly needed at each stage, and only provide that. The result is faster compilation times and the potential for improved cross-compilation support.

In this talk we will explain the design of the extension, the implementation and finally reflect on future directions the extension makes possible.

Typed Template Haskell allows us to write Haskell code which generates other Haskell programs in a type-safe and principled manner. However, the generated programs are completely opaque and cannot be introspected, limiting the type of analysis and transformations that we can perform. We propose a system which allows the programmer to overload the meaning of quoted Template Haskell expressions by desugaring these expressions into a well-typed PHOAS representation. Being a regular datatype, the PHOAS representation is much more amenable to analysis and transformation, indirectly giving the programmer the ability to overload the meaning of quoted expressions by further processing the PHOAS representation. Primitive Haskell constructs such as variables (both free and bound), lambda expressions and patterns are all exposed in the PHOAS interface, giving the programmer a large amount of control over the meaning of their quoted expressions. We believe that this system has a variety of useful applications, particularly for creating EDSLs - we give motivating examples in practical areas such as distributed computing and program generation to demonstrate the effectiveness of this approach. More precisely, in this paper we discuss the design and implementation of this idea as a new Haskell extension implemented on top of GHC.

The (slowly) ongoing project at github.com/blamario/language-haskell contains a full parser and pretty-printer for Haskell 2010 and almost all its extensions to date. The parser is built around the core design of a modular grammar built by combining grammar extension mixins. An extension mixin builds its part of the AST via a finally-tagless type class specific to the extension. We hope the end result will be a flexible parser that can be quickly tweaked to experiment with not only Haskell but many languages in the Haskell family.

In Mercury, we are developing a new Buck2-based Haskell build system and developer environment, starting from the first principles. We achieved module-level incremental build that can be distributed over a cluster. This progress involves many fundamental improvements in the GHC pipeline; opening GHC dependency analysis API to external build system, more complete build determinism, a better interface file design, first-class byte code artifacts, unifying GHC compilation modes and a new server-mode GHC worker. I overview our goal, the current development status and the next plan, which arrives in the next GHC releases and Buck2 Haskell rules integration.

RISC-V is an exciting, new architecture that has received a lot of attention by the Open Source community lately. We will start by understanding where this excitement comes from and why RISC-V is not just “yet another architecture”. We will also introduce some basic vocabulary to better understand requirements for compiler engineers and software packagers.

Then, we will take a look at the current state of RISC-V support in GHC with a focus on the Native Code Generation Backend (“NCG”.) Furthermore, future improvements will be discussed (finally, we’re at the dawn of Zurihac 2025 ;) .) A look at the innovative approaches to handle variable vector register widths in the instruction set may even inspire further research.

Implementing the RISC-V NCG was a challenge regarding software development environment setup, debugging and problem-solving strategies. There are a couple of tricks and hints be shared with future NCG developers. Most of them could be useful to tackle other tasks in the lower parts of the compiler pipeline as well.

A surprisingly large amount of haskell code uses the CPP extension to manage compilation for supporting multiple versions of GHC. For this, only a small subset of the available CPP features are used. Because CPP is a general-purpose tool, it makes unwanted changes to the code before GHC sees it, making it much harder for tools (and humans) to process. In my GHC_CPP proposal I present an alternative, built in to GHC, and providing just the needed subset for this use case.

This talk presents the motivation and rationale behind this, and shares progress to date on an implementation.