Jurriaan Hage Curry On 2017 Interview

Jurriaan Hage will be giving a talk at Curry On 2017. His talk is called Domain-Specific Type Error Diagnosis in the Glasgow Haskell Compiler.

Follow him on his Homepage and Facebook.

PurelyFunctional.tv: How did you get into Functional Programming?

Jurriaan Hage: It started with a course on functional programming and the lambda calculus at Leiden University where I studied, in 1991 or thereabouts. To pass we had to implement Simon Peyton Jones's book on implementing functional languages in Scheme. Then I did a PhD in esoteric combinatorics, but kept using Scheme if I could. Then I moved to Utrecht which was and still is a Haskell hotbed. I have taught Haskell to classes between 250 and 300 students, taught compilers and static analysis at master level where we typically use Haskell as the implementation language. I also maintain the Helium compiler for Haskell which is a compiler for Haskell 98 (minus some things) with a focus on type error diagnosis. It is available on Hackage.

PF.tv: What is your talk about?

JH: What I want to show is that with some slight modifications to the de facto standard Haskell compiler GHC, it is possible to manipulate the compiler so that for libraries that represent domain-specific languages (like parser combinator libraries and the diagrams library) you obtain domain-specific type error messages. I'll show how to do that in our branch of GHC and what's more: you can add this to any library by writing wrappers around the functions and type classes provided by it, and use GHC's type level programming abstractions (like type families) to engineer this in a clean and reusable fashion.

PF.tv: Who is your talk for?

JH: Any programmer of statically, strongly typed programming languages who has had to deal with obscure and/or domain-ignorant type error messages.

PF.tv: What do you hope people will take away from the talk?

JH: That GHC/Haskell with all those type level programming features that have been added along the way are a pretty good place to be when it comes to supporting domain-specific type error diagnosis.

Or, the slogan: programming expression level type errors by type level programming.

I also hope that it will show language designers and compiler builders of other languages what can be theirs if they adopt some of Haskell/GHC's concepts. I do not want Haskell to have the monopoly on domain-specific error diagnosis.

PF.tv: What concepts do you recommend people be familiar with to maximize their experience with the talk?

JH: The basics of Haskell's type system are important, or something akin to that (like ML's type system). Any knowledge of type level programming in Haskell will help, but I'll be giving some preliminaries on this.

PF.tv: What resources are available for people who want to study up before the talk?

JH: GHC/Type families is a good start for the type level programming

My PhD student Alejandro Serrano Mena and myself have published some work, in particular one at ESOP I am not sure though whether everyone can access this. This goes beyond what I shall be showing at Curry On!, since having all that seems to entail sizable changes to the way GHC does things right now. In fact, what we report on in the Curry On! talk are those things we would like to have in a compiler that are achievable with minimal changes to the compiler.

PF.tv: Where can people follow you online?

JH: My academic website at Utrecht.. I am on Facebook under my own name "Jurriaan Hage", but I do not talk much about programming and work there. I do not blog or anything, but have been active for a while on Quora.

PF.tv: Are there any projects you'd like people to be aware of? How can people help out?

JH: We certainly want people to try this out. I am looking in particular for people who have expertise in using particular Haskell libraries/EDSLs, that have suffered from domain-ignorant messages and that would like to experiment with improving this. If so, please contact us to obtain access to our branch of GHC (try J.Hage@uu.nl and/or A.SerranoMena@uu.nl).

Such contributions will teach us what limitations we still have (I expect quite a few) and how problematic these are, and it will allow us to build a collection of useful type level abstractions that one expects to be useful across different libraries.

PF.tv: Where do you see the state of functional programming in 10 years?

JH: To me, programming is not about the languages, but about languages that support particular concepts, like purity, laziness, parametric polymorphism, functions as first-class citizens (aka higher-order functions), and whatever else tickles your fancy. There is some room here for taste: whenever you combine mutliple concepts, and package them up in a language, there seem to be ways of doing so that differ in the extent into which a concept is available and how it cleanly interacts with others. In that respect, I think Haskell is a very elegant way of combining such features.

In terms of the future, it seems to me that besides the problem of type error diagnosis, particularly for the more advanced facilities like type families and GADTs, what I miss most in Haskell is control over the resource consumption of programs. High-level programming languages are not the best place to be for low-level control.

Clearly, not many programs actually need such control, but when you start to want to build sizable applications in, say, Haskell, then ch ances are there are parts of those systems where having this control is essential. Not having this level of control will make companies opt for lower level languages instead, which is a shame. So what I hope, and what I want to contribute to myself, is making this level of control possible in a way that is practically usable by professional programmers.

Since we are on the subject of usability, it would be great if dependently typed programming could become a mainstay of functional programming. But I am not convinced yet that the usability of these languages can be so improved that they come within reach of the general programming population. But who knows what will happen in ten years time. This is also something I'll be looking at in the next five years.

PF.tv: If functional programming were a superhero, what superpower would it have?

JH: Higher-order functions (functions that take functions as arguments, or return them as results) are to me the most important, with parametric polymorphism (writing functions that work, say, for any list irrespective of the type of the element) a close second. Together they enable a huge amount of code reuse.