You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -13,13 +13,8 @@ In the past the Haskell Implementors' Workshop was co-located with ICFP (Interna
13
13
14
14
## Call for Proposals
15
15
16
-
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.
17
-
18
-
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).
19
-
20
-
* Extended CFP Deadline: April 18, 2025
21
-
* Speaker Notification: May 5, 2025
22
-
* Talk format: 20min talk + 5min Q/A
16
+
The call for proposals is closed. The [program](#program) can be found further below.
17
+
Lightning talks will be scheduled on the day of the event.
23
18
24
19
### Scope and Target Audience
25
20
@@ -50,12 +45,6 @@ We will also have a lightning talks session. Lightning talks should be ~7mins an
50
45
* Ian-Woo Kim
51
46
* Andreas Herrmann (chair)
52
47
53
-
<!--
54
-
## Speakers
55
-
56
-
The following speakers will present at the event. A detailed program is provided further below.
57
-
-->
58
-
59
48
## In-Person Attendance
60
49
61
50
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
100
89
101
90
### Program
102
91
103
-
The program will be announced after the call for proposals closed and the program committee selected the speakers.
<tr><td> 9:15</td><td>10:15</td><td>GHC Status Report</td><td>Andreas Klebinger<br>& Ben Gamari</td></tr>
99
+
100
+
<tr><td>10:15</td><td>10:40</td><td><details>
101
+
<summary>Required Type Arguments</summary>
102
+
<p>
103
+
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
113
+
of a modern integration with IDEs, and incomplete, slow, or unimplemented
114
+
features, has greatly hindered its adoption.
115
+
</p>
116
+
<p>
117
+
In this talk, we introduce our progress and plans to create a first-class
118
+
debugger for Haskell. We've developed a standalone application using the
119
+
GHC library that conforms to the Debug Adaptor Protocol (DAP), making Haskell
120
+
debugging possible with all compatible IDEs. In the process, we've fixed long-standing performance
121
+
and usability issues in the existing debugger implementation. Our goal is to bring
122
+
debugging of Haskell programs to the same level as other language ecosystems.
123
+
Finally, we’ll also reflect on the architectural limitations of the current debugger and
124
+
outline our vision for the future of debugging in Haskell.
125
+
</p>
126
+
</details></td><td>Rodrigo Mesquita</td></tr>
127
+
<tr><td>11:15</td><td>11:40</td><td><details>
128
+
<summary>More Buck for your Bang - Lifting BangPatterns to the Type Level</summary>
129
+
<p>
130
+
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.
131
+
</p>
132
+
<p>
133
+
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?
134
+
</p>
135
+
<p>
136
+
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.
137
+
</p>
138
+
<p>
139
+
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?
140
+
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?
141
+
</p>
142
+
</details></td><td>Andreas Klebinger</td></tr>
143
+
<tr><td>11:40</td><td>12:05</td><td><details>
144
+
<summary>Catching space leaks at compile-time using th-deepstrict</summary>
145
+
<p>
146
+
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.
147
+
</p>
148
+
</details></td><td>Teo Camarasu</td></tr>
149
+
<tr><td>12:05</td><td>12:30</td><td><details>
150
+
<summary>Making GHCi compatible with multiple home units</summary>
151
+
<p>
152
+
The ability to compile multiple units within a single session was a key
153
+
innovation for GHC API consumers like GHCi and HLS. Today, most Haskell
154
+
projects involve multiple local packages that developers actively modify, so
155
+
tooling must support this workflow seamlessly.
156
+
</p><p>
157
+
However, GHCi's support for multiple home units remains limited.
158
+
This significantly hampers productivity when working on
159
+
multi-package projects. When developers start using multiple unit repl support,
160
+
they expect the same experience as the old single-unit session.
161
+
</p><p>
162
+
In this talk, we present our approach to making GHCi fully compatible with
163
+
multiple home units. Our goal is to deliver a seamless user experience: using
164
+
GHCi with multiple home units should feel no different from working with a
165
+
single unit. To achieve this, we are redesigning GHC's interactive session
166
+
management with multiple home units as the default model, treating single-unit
167
+
sessions as a special case.
168
+
</p><p>
169
+
This unification eliminates fragile, infrequently used code paths, reduces
170
+
test duplication and provides feature parity. Furthermore, GHCi's built-in
171
+
debugger will work transparently across unit boundaries, for example, allowing
172
+
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
182
+
more precise about which dependencies are needed for Template Haskell.
183
+
In a module, each import is annotated with which level it will be needed at,
184
+
some modules will be needed for use in splices, some in quotes and some in
185
+
normal contexts.
186
+
</p>
187
+
<p>
188
+
This precision means it is straightforward
189
+
for the compiler to work out what is exactly needed at each stage, and
190
+
only provide that. The result is faster compilation times and the potential
191
+
for improved cross-compilation support.
192
+
</p>
193
+
<p>
194
+
In this talk we will explain the design of the extension, the implementation and
195
+
finally reflect on future directions the extension makes possible.
196
+
</p>
197
+
</details></td><td>Matthew Pickering</td></tr>
198
+
<tr><td>14:25</td><td>14:50</td><td><details>
199
+
<summary>Intensional Analysis of Typed Template Haskell Quotations</summary>
200
+
<p>
201
+
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.
202
+
</p>
203
+
</details></td><td>Ellis Kesterton</td></tr>
204
+
<tr><td>14:50</td><td>15:15</td><td><details>
205
+
<summary>Modular grammar and parser for Haskell with extensions</summary>
206
+
<p>
207
+
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.
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
223
+
the Open Source community lately. We will start by understanding where this
224
+
excitement comes from and why RISC-V is not just "yet another architecture".
225
+
We will also introduce some basic vocabulary to better understand requirements
226
+
for compiler engineers and software packagers.
227
+
</p><p>
228
+
Then, we will take a look at the current state of RISC-V support in GHC with a
229
+
focus on the Native Code Generation Backend ("NCG".) Furthermore, future
230
+
improvements will be discussed (finally, we're at the dawn of Zurihac 2025 ;)
231
+
.) A look at the innovative approaches to handle variable vector register
232
+
widths in the instruction set may even inspire further research.
233
+
</p><p>
234
+
Implementing the RISC-V NCG was a challenge regarding software development
235
+
environment setup, debugging and problem-solving strategies. There are a couple
236
+
of tricks and hints be shared with future NCG developers. Most of them could be
237
+
useful to tackle other tasks in the lower parts of the compiler pipeline as
238
+
well.
239
+
</p>
240
+
</details></td><td>Sven Tennie</td></tr>
241
+
<tr><td>16:35</td><td>17:00</td><td><details>
242
+
<summary>An alternative to CPP</summary>
243
+
<p>
244
+
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.
245
+
</p><p>
246
+
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>.
0 commit comments