diff --git a/events/2025-haskell-implementors-workshop.markdown b/events/2025-haskell-implementors-workshop.markdown index 654af2c8..42f0f328 100644 --- a/events/2025-haskell-implementors-workshop.markdown +++ b/events/2025-haskell-implementors-workshop.markdown @@ -13,13 +13,8 @@ In the past the Haskell Implementors' Workshop was co-located with ICFP (Interna ## Call for Proposals -Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. There will be no published proceedings. The workshop will be informal and interactive, with open spaces in the timetable and room for ad-hoc discussion, demos, and lightning talks. - -The CFP is open and talks can be submitted using [the online form](https://docs.google.com/forms/d/e/1FAIpQLSdczGbxJYGc4eusvPrxwBbZl561PnKeYnoZ2hYsdw_ZpSfupQ/viewform?usp=header). - -* Extended CFP Deadline: April 18, 2025 -* Speaker Notification: May 5, 2025 -* Talk format: 20min talk + 5min Q/A +The call for proposals is closed. The [program](#program) can be found further below. +Lightning talks will be scheduled on the day of the event. ### Scope and Target Audience @@ -50,12 +45,6 @@ We will also have a lightning talks session. Lightning talks should be ~7mins an * Ian-Woo Kim * Andreas Herrmann (chair) - - ## In-Person Attendance Registration is open. Please sign up [on Eventbrite](https://www.eventbrite.com/e/2025-workshops-at-zurihac-tickets-1247256801669?aff=oddtdtcreator). Registrations for both the Haskell Ecosystem Workshop (HEW) and Haskell Implementors' Workshop (HIW) are managed using the same ticketing system. **Please make sure to include a Haskell Implementors' Workshop ticket in your booking.** @@ -100,7 +89,168 @@ You are invited to bring the necessary equipment to work on GHC (laptop, power a ### Program -The program will be announced after the call for proposals closed and the program committee selected the speakers. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
StartEndTitleSpeaker(s)
8:009:00Registration
9:009:15Welcome & Introduction
9:1510:15GHC Status ReportAndreas Klebinger
& Ben Gamari
10:1510:40
+ Required Type Arguments +

+ 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. +

+
Vladislav Zavialov
10:4010:50break
10:5011:15
+ The GHC Debugger +

+ 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. +

+
Rodrigo Mesquita
11:1511:40
+ More Buck for your Bang - Lifting BangPatterns to the Type Level +

+ 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? +

+
Andreas Klebinger
11:4012:05
+ Catching space leaks at compile-time using th-deepstrict +

+ 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. +

+
Teo Camarasu
12:0512:30
+ Making GHCi compatible with multiple home units +

+ 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. +

+
Hannes Siebenhandl
12:3014:00lunch
14:0014:25
+ Explicit Level Imports +

+ 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. +

+
Matthew Pickering
14:2514:50
+ Intensional Analysis of Typed Template Haskell Quotations +

+ 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. +

+
Ellis Kesterton
14:5015:15
+ Modular grammar and parser for Haskell with extensions +

+ 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. +

+
Mario Blažević
15:1515:40
+ Towards Dream Haskell Build Experience +

+ 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. +

+
Ian-Woo Kim
15:4016:10break
16:1016:35
+ GHC's RISC-V Native Code Generation Backend +

+ 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. +

+
Sven Tennie
16:3517:00
+ An alternative to CPP +

+ 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. +

+
Alan Zimmerman
17:0017:50lightning talks
17:5018:00closing
### Lunch and Refreshments