From 4d4c40f8a5b9c88edcf5eda626c5f21971d5aa94 Mon Sep 17 00:00:00 2001
From: Christiaan Baaij <christiaan.baaij@gmail.com>
Date: Tue, 12 May 2026 21:03:02 +0200
Subject: [PATCH] Add program

---
 ...026-haskell-implementors-workshop.markdown | 195 ++++++------------
 1 file changed, 65 insertions(+), 130 deletions(-)

diff --git a/events/2026-haskell-implementors-workshop.markdown b/events/2026-haskell-implementors-workshop.markdown
index 7167ed6c..6440e376 100644
--- a/events/2026-haskell-implementors-workshop.markdown
+++ b/events/2026-haskell-implementors-workshop.markdown
@@ -13,7 +13,7 @@ In the past the Haskell Implementors' Workshop was co-located with ICFP (Interna
 
 ## Practical Information and Schedule
 
-The workshop will be held at the [Rapperswil-Jona campus of OST](https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona-campus). It is right next to the Rapperswil train station, at [Oberseestrasse 10](https://goo.gl/maps/DkF6U9qdgdjcMfz29). The [Zurihac 2025 site](https://zfoh.ch/zurihac2025/) has instructions for transportation between Rapperswil and Zürich.
+The workshop will be held at the [Rapperswil-Jona campus of OST](https://www.ost.ch/en/university-of-applied-sciences/campus/rapperswil-jona-campus). It is right next to the Rapperswil train station, at [Oberseestrasse 10](https://goo.gl/maps/DkF6U9qdgdjcMfz29). The [Zurihac 2026 site](https://zfoh.ch/zurihac2026/) has instructions for transportation between Rapperswil and Zürich.
 
 <!--
 All talks and presentations will be held in an air-conditioned classroom that will be configured conference-style, which means that most seats won't have a table or desk attached. During the event, we'll let you know which additional spaces are good for compiler hacking. We will post the exact room number when that becomes available.
@@ -21,178 +21,113 @@ All talks and presentations will be held in an air-conditioned classroom that wi
 
 ### Program
 
-The exact program will follow at a later date.
-
-<!--
 <table>
   <tr><th>Start</th><th>End</th><th>Title</th><th>Speaker(s)</th></tr>
 
   <tr><td> 8:00</td><td>9:00</td><td>Registration</td><td></td></tr>
-  <tr><td> 9:00</td><td>9:15</td><td>Welcome & Introduction</td><td><small>chair: Andreas Herrmann</small></td></tr>
+  <tr><td> 9:00</td><td>9:15</td><td>Welcome & Introduction</td><td><small>chair: Christiaan Baaij</small></td></tr>
 
-  <tr><td> 9:15</td><td>10:15</td><td>GHC Status Report</td><td>Andreas Klebinger<br>& Ben Gamari</td></tr>
+  <tr><td> 9:15</td><td>10:15</td><td>GHC Status Report</td><td>Andreas Klebinger</td></tr>
 
   <tr><td>10:15</td><td>10:40</td><td><details>
-    <summary>Required Type Arguments</summary>
+    <summary>Stable Haskell</summary>
     <p>
-      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.
+      Stable Haskell is an effort to fix Haskell tooling and drive stability in the ecosystem. We're working on making GHC easier to build (with cabal), fixing cross compilers and allow easy shipping of alternative distributions. Also see <a href=https://github.com/stable-haskell>https://github.com/stable-haskell</a>
     </p>
-  </details></td><td>Vladislav Zavialov</td></tr>
+  </details></td><td>Julian Ospald</td></tr>
 
-  <tr><td>10:40</td><td>10:50</td><td>break</td><td><small>chair: Jaro Reinders</small></td></tr>
+  <tr><td>10:40</td><td>11:00</td><td>break</td><td><small>chair: TBD</small></td></tr>
 
-  <tr><td>10:50</td><td>11:15</td><td><details>
-    <summary>The GHC Debugger</summary>
-    <p>Collaborators: Matthew Pickering, Hannes Siebenhandl</p>
+  <tr><td>11:00</td><td>11:25</td><td><details>
+    <summary>MicroHs Dead or Alive? - A status report</summary>
     <p>
-      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.
+      I will present what's new in MicroHs and have some demos.
     </p>
+  </details></td><td>Lennart Augustsson</td></tr>
+  <tr><td>11:30</td><td>11:55</td><td><details>
+    <summary>Lightweight profiling with `ghc-stack-profiler`</summary>
     <p>
-      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.
+    Profiling provides insight into the run-time performance characteristics of a program.
+    GHC supports compiling programs with additional instrumentation for profiling.
+    Instrumented programs can produce detailed reports about their runtime.
+    However, instrumentation has a significant compile-time cost and performance impact, both in memory allocations and execution time.
+    Additionally, cost-centre instrumentation affects optimisations, which can further distance the profiled program from its runtime behaviour under non-profiled conditions.
     </p>
-  </details></td><td>Rodrigo Mesquita</td></tr>
-  <tr><td>11:15</td><td>11:40</td><td><details>
-    <summary>More Buck for your Bang - Lifting BangPatterns to the Type Level</summary>
     <p>
-      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 <code>plus :: !Int -> !Int -> Int</code> seems trivial at first glance as the concept seems to translate to such a type signature quite easily.
+    [`ghc-stack-profiler`](https://github.com/well-typed/ghc-stack-profiler) is a lightweight alternative to existing profiling mechanisms in GHC.
+    Unlike the existing profiling instrumentation in GHC, it doesn't need specific support from the RTS, and dependencies don't need to be recompiled either.
+    It takes a snapshot of the RTS callstack of a running Haskell thread, serialises this snapshot sample and writes it to the eventlog at fixed intervals.
+    The frames of the RTS callstack have source information attached to them via `-finfo-table-map`, yielding human-readable stack traces with file and line information.
+    Since raw RTS callstacks can be difficult to interpret, `ghc-stack-profiler` supports [GHC's stack annotation](https://www.well-typed.com/blog/2025/09/better-haskell-stack-traces/) frames.
+    This gives developers more control over profiling, while noticeably improving readability.
     </p>
     <p>
-      But what might a type signature like <code>filter :: (!Int -> Bool) -> [Int] -> Bool</code> tell us? And more importantly what can a compiler make out of it?
+    In this talk, we present `ghc-stack-profiler`, discuss its implementation details, and its relation to stack annotations.
+    Moreover, we cover how to use it effectively, and showcase different tools to visualize the performance profiles it produces.
     </p>
     <p>
-      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.
+    Collaborators: Matthew Pickering, Wen Kokke
     </p>
+  </details></td><td>Hannes Siebenhandl</td></tr>
+  <tr><td>12:00</td><td>12:25</td><td><details>
+    <summary>Evolving the Haskell Debugger</summary>
     <p>
-      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?
+    The new Haskell debugger is an increasingly robust and useful tool to find bugs in your codebase.
+    In fact, the debugger is already being useful in debugging both GHC and the debugger itself.
     </p>
-  </details></td><td>Andreas Klebinger</td></tr>
-  <tr><td>11:40</td><td>12:05</td><td><details>
-    <summary>Catching space leaks at compile-time using th-deepstrict</summary>
     <p>
-      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 <a href="https://tracsis.github.io/th-deepstrict/">th-deepstrict</a> 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.
+    Besides fixing bugs and supporting more Debug Adapter Protocol (DAP) features, a few recent changes are particularly important for debugging reasonably complex programs:
+    <ul>
+    <li>Custom user-given `DebugView` instances</li>
+    <li>Stack frames and per-frame variables</li>
+    <li>Source locations and stack traces for exceptions</li>
+    <li>And using the external interpreter by default (for multi-threaded support and isolation).</li>
+    </ul>
     </p>
-  </details></td><td>Teo Camarasu</td></tr>
-  <tr><td>12:05</td><td>12:30</td><td><details>
-    <summary>Making GHCi compatible with multiple home units</summary>
-    <p>Collaborators: Matthew Pickering, Rodrigo Mesquita</p>
     <p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
+    In this talk, we revisit the latest or ongoing work on the Haskell Debugger, and the necessary GHC changes to support it, with a focus on the changes mentioned before.
     </p>
-  </details></td><td>Hannes&nbsp;Siebenhandl</td></tr>
-
-  <tr><td>12:30</td><td>14:00</td><td>lunch</td><td><small>chair: Luite Stegeman</small></td></tr>
+  </details></td><td>Rodrigo Mesquita</td></tr>
+  <tr><td>12:25</td><td>14:00</td><td>lunch</td><td><small>chair: TBD</small></td></tr>
 
-  <tr><td>14:00</td><td>14:25</td><td><details>
-    <summary>Explicit Level Imports</summary>
-    <p>Collaborators: Rodrigo Mesquita, Adam Gundry</p>
-    <p>
-      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.
-    </p>
+  <tr><td>14:00</td><td>14:45</td><td><details>
+    <summary>Is There a Future for a Formally Specified Haskell Report</summary>
     <p>
-      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.
+    Despite giant leaps in both our theoretical understanding of programming languages on the one hand, and the usability of proof assistants on the other hand, we are still living with languages that are specified in natural, semi-formal language.
+    For a while I have been asking myself what the essential difficulties are when it comes to writing a completely formal, mechanized specification of Haskell.
+    Haskell has been specified in multiple official Haskell reports, as well as academic articles which describe many different aspects in more detail.
+    From precise grammars for indentation sensitive languages, to the specification of its module system, type inference system and type classes, most non-trivial aspects of Haskell have been the subject of some detailed investigation.
+    Most of these articles can be formalized by a competent proof assistant user in a relatively short amount of time.
+    How much more work would be required if we tried to combine them all? I will present my work on writing a fully verified Haskell frontend in the proof assistant Lean, as well as a mechanized version of K-F Faxen's declarative specification of Haskell's type system.
     </p>
     <p>
-      In this talk we will explain the design of the extension, the implementation and
-finally reflect on future directions the extension makes possible.
+    (Content will be similar to a presentation I gave at our research group in Kent: <a href=https://binderdavid.github.io/talks/haskell-spec-plas.pdf>https://binderdavid.github.io/talks/haskell-spec-plas.pdf</a>)
     </p>
-  </details></td><td>Matthew Pickering</td></tr>
-  <tr><td>14:25</td><td>14:50</td><td><details>
-    <summary>Intensional Analysis of Typed Template Haskell Quotations</summary>
-    <p>Collaborators: Matthew Pickering</p>
-    <p>
-      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.
-    </p>
-  </details></td><td>Ellis Kesterton</td></tr>
+  </details></td><td>David Binder</td></tr>
   <tr><td>14:50</td><td>15:15</td><td><details>
-    <summary>Modular grammar and parser for Haskell with extensions</summary>
+    <summary>Towards better implicit parameters</summary>
     <p>
-      The (slowly) ongoing project at <a href="https://github.com/blamario/language-haskell">github.com/blamario/language-haskell</a> 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.
+      GHC provides an implementation of dynamic scoping via the ImplicitParams extension. Unfortunately this feature suffers from various limitations, in particular lack of abstraction and no way to solve naming conflicts.
+As an attempt to improve on the current situation, I submitted a GHC proposal called "Scoped values", which introduces a new mechanism for dynamic scoping. The main difference from ImplicitParams is that keys are not flat Symbols but nominal data types.
+While the proposal was met with mixed reactions and was ultimately closed, I believe the exercise was valuable: it presented interesting compiler design choices, and the discussion helped surface a more general solution, itself with its own trade-offs and open questions.
     </p>
-  </details></td><td>Mario Blažević</td></tr>
-  <tr><td>15:15</td><td>15:40</td><td><details>
-    <summary>Towards Dream Haskell Build Experience</summary>
-    <p>
-      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.
-      </p>
-  </details></td><td>Ian-Woo Kim</td></tr>
+  </details></td><td>Lorenzo Tabacchini</td></tr>
 
-  <tr><td>15:40</td><td>16:10</td><td>break</td><td><small>chair: Rodrigo Mesquita</small></td></tr>
+  <tr><td>15:15</td><td>15:45</td><td>break</td><td><small>chair: TBD</small></td></tr>
 
-  <tr><td>16:10</td><td>16:35</td><td><details>
-    <summary>GHC's RISC-V Native Code Generation Backend</summary>
+  <tr><td>15:45</td><td>16:30</td><td><details>
+    <summary>GHC String interpolation</summary>
     <p>
-      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.
-    </p><p>
-      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.
-    </p><p>
-      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.
+      I will be going over my 3+ year old proposal adding native string interpolation to GHC: https://github.com/ghc-proposals/ghc-proposals/pull/570. The talk will include a demo, but will focus on addressing comments/questions to fuel excitement for the feature.
     </p>
-  </details></td><td>Sven Tennie</td></tr>
-  <tr><td>16:35</td><td>17:00</td><td><details>
-    <summary>An alternative to CPP</summary>
-    <p>
-      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 <a href="https://github.com/ghc-proposals/ghc-proposals/pull/616">my GHC_CPP proposal</a> I present an alternative, built in to GHC, and providing just the needed subset for this use case.
-    </p><p>
-      This talk presents the motivation and rationale behind this, and shares progress to date on <a href="https://gitlab.haskell.org/ghc/ghc/-/tree/wip/az/ghc-cpp">an implementation</a>.
-    </p>
-  </details></td><td>Alan Zimmerman</td></tr>
+  </details></td><td>Brandon Chinn</td></tr>
 
-  <tr><td>17:00</td><td>17:50</td><td>lightning talks</td><td></td></tr>
+  <tr><td>16:30</td><td>17:20</td><td>lightning talks</td><td></td></tr>
 
-  <tr><td>17:50</td><td>18:00</td><td>closing</td><td></td></tr>
+  <tr><td>17:20</td><td>17:30</td><td>closing</td><td></td></tr>
 </table>
 
-Please submit topics for lightning talks using [this form](https://forms.gle/tbJHf2wzWqHKQtZW7).
--->
+Please submit topics for lightning talks using [this form](https://forms.gle/TWkMtrT9d4in2fsw5).
 
 ### In-Person Attendance