Accelerate is a library to achieve high performance for numeric algorithms (such as those found in graphics, simulations, and machine learning) on multicore CPU and GPU systems. Accelerate doesn’t achieve this by forcing you to write low-level monadic code, but by encouraging high-level purely functional code.

You guessed it. There is a price to pay. In Accelerate, you need to write your numeric array algorithms in an embedded language. That language is a subset of Haskell designed to facilitate high-performance data parallel algorithms. The rest of your program is still plain Haskell.

Accelerate comes with custom backends that translate code written in the embedded language into highly optimised machine code. That code gets efficiently scheduled onto multicore CPU and GPU systems by a custom runtime system.

In this talk, I like to achieve three goals: (1) I want to enable you to use Accelerate to implement numeric algorithms; (2) I want to provide a high-level outline of how Accelerate works; and (3) I want to encourage you to use Accelerate or even contribute to it. The first goal is in reach, even for beginning Haskell users. For the second goal, we will have to dive deeper, but I’ll keep it accessible with examples and thorough explanations. And finally, to use Accelerate effectively, it is more important to understand the algorithm that you want to implement than to be a Haskell expert.

C has a library for everything, and those libraries are fast, battle-tested, and maintained by somebody else. Reaching them from Haskell is the hard part: a Haskell-native rewrite is a project of its own, and hand-writing bindings is tedious and error-prone. hs-bindgen automatically generates those bindings for you.

In this talk, we explore the vision and the architecture behind hs-bindgen: a compiler whose source language is C headers and whose target is Haskell modules. We discuss some challenges of reconciling C's low-level memory model with Haskell's rich type system. I hope to convince you that using a C library from Haskell is less like a project of its own and more like an afternoon's work.

As Haskell developers, we love to talk about equational reasoning, type safety, compositionality, parametricity, and so on. These are great for reasoning about what the program computes, and they rest on a semantics that deliberately abstracts away many of the things compilers do. But they say much less about many concerns that matter in practice: how fast a program runs, what it allocates, why an optimization did or didn’t fire, or why the compiler is producing a baffling error.

This talk argues that a good understanding of your compiler can make you a much better functional programmer. Through a series of examples, including some surprising ones, we’ll see how looking past the source language can sharpen our intuition, challenge common assumptions, and help us write better programs.

In this talk I am going to take a look at how we got to the current Haskell report, how it changed over the decades, and present the work we are currently undertaking to update it. I will present my own ideas on what the role of the language report can be going forward, but we will hopefully also discuss how the language report can fit with the GHC and CLC proposal processes to document and specify the language we love to use.

A doctor friend asked me to build a patient scheduling platform. With no team to cover the database, frontend, and UX, AI agents filled the gaps — my first real chance to use Haskell as the primary language for a real application, built around a typed domain model as the AI agent's specification.

Whenever complexity piled up, pushing correctness back into the domain model almost always helped: a sprawl of possible transitions collapsed into a forward-only process through a few states, and whole categories of "can it go back to that state?" bugs simply stopped being askable.

But that strategy has a limit. Two staff claiming the same request at once depends on timing the type checker was never given as input — the model can't rule out what it was never told about.

Takeaway: `Domain.hs` is a real specification for an AI agent — but only as far as the facts it's actually given. Concurrency is where this experiment found that boundary.