HaskellImplementorsWorkshop/2015

The Haskell implementors' workshop is a forum for those involved in implementing Haskell systems, infrastructure, libraries and tools, generally for people involved in implementing Haskell technology, to share their work and discuss future directions and collaborations with others.

In 2015, the Haskell Implementors Workshop will be co-located with ICFP 2015 in Vancouver.

The workshop does not have proceedings. Talks and/or demos are proposed by submitting an abstract, and selected by a small program committee. The workshop will be informal and interactive, with a flexible timetable and plenty of room for ad-hoc discussion, demos, and impromptu short talks.

Traditionally, HIW is an open forum for people writing compilers, tools, or libraries, people with cool ideas for directions in which we should take the platform, proposals for new features to be implemented, and half-baked crazy ideas. For more details see the Call for Contributions in full.

Links

• Call for Contributions
• HotCRP Submission page

Important Dates

• Tuesday, 4 August, 2015: Talk Proposal Deadline (anywhere on earth)
• Monday, 10 August, 2015: Notification
• Sunday, 30 August, 2015: Workshop

Programme

09:00	Welcome to HIW 2015
09:05-10:00	Session 1
09:05	State of the GHC
09:35	State of the GHCJS (slides)
10:00 - 10:30	Coffee Break
10:30-12:00	Session 2
10:30	API Annotations - enabler for source code round tripping / modification (slides)
11:00	Using hardware transactions in the GHC runtime system (slides)
11:30	Rebooting supercompilation for GHC (slides)
12:00-14:00	Lunch
14:00-15:30	Session 3
14:00	Securing our package distribution system (slides)
14:25	Introduction to the 'stack' build tool
14:50	"Look Ma, No Signatures!" Separate modular development without interfaces (slides)
15:15	Haskell.org Infrastructure Status Update (slides)
15:30-16:00	Coffee Break
16:00-18:00	Session 4
16:00	A Pretty-Printer that Says what it Means
16:30	Levity Polymorphism in Dependent Haskell (slides)
17.00	Lightning talks

Lightning talks:

• Talk 1: It's the data, stupid (Ryan Newton)
• Talk 2: GHC Performance Dashboard (Joachin Brietner)
• Talk 3: JITs for Haskell (Comeron Swords, Spenser Bauman)
• Talk 4: Into the fold (Ryan Scott)
• Talk 5: Unlifted data structures (Edward Kemett)
• Talk 6: Progress on cabal and hackage (Duncan Coutts)
• Talk 7: Deterministic GHC compilation (Bartosz Nitka)
• Talk 8: Declaration-based code distribution (Philipp Schuster)

Abstracts of Accepted Talks

The state of GHCJS

Luite Stegeman

GHCJS is a Haskell to JavaScript compiler based on GHC. Among the improvements in the past year are official Cabal integration, support for CPU profiling and an overhaul of the ghcjs-base library. A recent addition is an experimental REPL, making it easier than ever to interact with Haskell in a browser or node.js environment.

I will discuss the current state of GHCJS and the ongoing work on the new code generator, including the plans on how to make the most out of the new ECMAScript 2015 features.

API Annotations - enabler for source code round tripping / modification

Alan Zimmerman

GHC developers will have seen a large number of commits over the last months for API Annotations.

This talk will focus on what they are, what they are intended for, and show how they are used to round trip source code in ghc-exactprint, which paves the way for a general-purpose haskell source modification library.

It will touch on the design principles in ghc-exactprint, and will include demonstrations of use in HaRe and Matt Pickering's GSOC project to apply HLint hints directly.

Using hardware transactions in the GHC runtime system

Ryan Yates and Michael L. Scott (University of Rochester)

Hardware support for transactional memory (HTM) is now mainstream with commercial offerings from both Intel and IBM. This new flexible hardware tool for synchronization gives opportunities to improve the performance of language-level synchronization and to simplify runtime system implementation. Our research has shown that concurrent data structure performance in GHC is limited when taking the simple but common approach of atomically updating a global mutable reference to the root of a pure-functional structure. Transactional memory (both the existing software implementation and our hybrid hardware/software implementation) shows much better performance as the core count grows. Our current work aims to further improve performance by reducing the overhead of transactional memory in GHC while still supporting such powerful high-level features as retry and orElse. In our talk we will share our benchmark results on a 72-thread Intel machine with HTM, details on how we have found HTM useful in the GHC runtime system, opportunities to explore other uses of HTM, and some lessons learned while working with GHC.

(This work was funded in part by the National Science Foundation under grants CCR-0963759, CCF-1116055, CCF-1337224, and CCF-1422649, and by support from the IBM Canada Centres for Advanced Studies.)

Slides

Rebooting supercompilation for GHC

Ömer S. Ağacan and Ryan R. Newton (Indiana University)

GHC's purely functional intermediate language Core, and API for Core-to-Core transformations, make it a great language for experimenting with program transformation ideas. These program transformers can be distributed as libraries, avoiding merging experimental ideas into GHC while making it possible for users to gain advantage of those transformers immediately.

These compiler plugins, however, are not yet used much in the wild [1]. In the future, we hope to see both more specialized optimizers and extreme optimization modes (“-O99”). In this talk, I will give an overview of recent developments in program-transformation-based optimizations of Haskell, and its history (à la Peyton-Jones and Santos, 1997), with focus on the supercompilation work of Mitchell [2] and Bolingbroke [3]. I argue that it is worth rebooting supercompilation work in GHC, with the aim of providing a compiler plugin as an optional tool for libraries that benefit from it. I will describe my preliminary work in this area, and discuss future directions.

Lastly, as a new PhD student, I'm going to ask audience for feedback, further ideas and collaborators for Haskell program-transformation-based optimizations and supercompilation work.

[1]: One example that makes use of it is SYB optimizer described in the paper "Optimizing SYB is Easy!" by Adams et al.

[2]: Rethinking supercompilation, ICFP '10.

[3]: Call-by-need supercompilation, PhD thesis.

Securing our package distribution system

Duncan Coutts and Edsko de Vries (Well-Typed)

As Haskell has gained in popularity and profile there has been increasing pressure to properly secure our package distribution system. This is no small problem as crypto system design is notoriously subtle.

This talk presents the design and implementation of a system to improve the security of the distribution channel between authors and users via Hackage repositories and mirrors. To reduce the dangers of poor crypto design the system is an adaptation of an existing design from the academic literature called The Update Framework.

We will introduce The Update Framework, the details of the adaptation to fit the existing Hackage distribution system, and exactly what security guarantees it provides. We will cover the current state of the implementation and other system benefits such as improved performance and reliability from being able to use mirrors -- without having to trust those mirrors.

Introduction to the 'stack' build tool

Emanuel Borsboom (FP Complete)

Stack is a cross-platform tool for developing Haskell projects, aimed at Haskellers both new and experienced. I will discuss its features and advantages over the current approach, a brief demo of how to use the tool, how it fits into the existing ecosystem, and what it is not.

Slides (markdown)

"Look Ma, No Signatures!" Separate modular development without interfaces

Edward Z. Yang (Stanford University)

Standard practice in the Haskell community is to directly depend on libraries you need, specifying the acceptable choice of libraries by version bounds. The Backpack project seeks to raise the level of type-safety, by giving users the tool-support they need to talk interfaces rather than version ranges. Unfortunately, if hs-boot files are any indication, Haskell users hate having to write their type signatures multiple times. In this talk, I want describe a proposal for inferring Backpack signatures from modules. The key idea? Use multiple levels of hs-boot files. There are many benefits (say goodbye to hs-boot files of all types) and also some dangers (how should we manage data kind promotion?)

Haskell.org Infrastructure Status Update

Gershom Bazerman (Haskell.org Committee)

This brief (ten minute) informational talk will run through the current state of core haskell.org infrastructure -- what has been accomplished in the last year, and what issues remain outstanding to address.

Slides

A Pretty-Printer that Says what it Means

David Raymond Christiansen (IT University of Copenhagen)

Information from our development tools should be more than mere strings. Regions of the output refer to actual language concepts, but this linkage between sense and reference is lost during ordinary pretty-printing. Making this linkage explicit enables clients of the pretty-printer to produce a variety of innovative and useful tools.

The pretty-printing library used in Idris abstracts its type of documents over arbitrary semantic annotations. This has enabled a surprising variety of interaction patterns, both in editor modes and other tools. In this talk, I'll describe the approach taken by Idris's pretty-printing library as well as demonstrate some of the applications that this has enabled, with an eye towards their potential implementation in Haskell compilers.

Levity Polymorphism in Dependent Haskell

Richard A. Eisenberg (University of Pennsylvania)

Along the way to making Haskell dependently typed, it is necessary to introduce explicit kind equalities, much like the explicit type equalities already present in GHC. The theory behind this idea is explored in previous work [1]. However, in implementing kind equalities, several practical challenges presented themselves.

This talk will focus on one such challenge: resolving GHC's sub-kinding story. GHC 7.10 (and many previous versions) has a base kind * that classifies lifted types (that is, types inhabited by bottom) and a separate base kind # that classifies unlifted types. There is a third kind, spelled OpenKind, that is a super-kind to both * and #. This is necessary to allow, for example, exceptions to be thrown in a context expecting an unlifted type. However, mixing explicit kind equalities and a sub-kinding relationship would be quite intricate. Instead, we use polymorphism to model sub-typing by introducing so-called levity variables and indexing the base kinds by these levity variables. The details will be in the talk. One upshot of this solution is that it will be possible for Haskellers to write their own functions that work at both * and # kinds, something impossible today.

This talk will also include time to demo a working implementation of GHC that merges types with kinds and reasons about kind equalities.

[1]: Stephanie Weirich, Justin Hsu, and Richard A. Eisenberg. "System FC with Explicit Kind Equality". ICFP '13.

Slides

Programme Committee

• Christopher Brown (St. Andrews University)
• Richard Eisenberg (University of Pennsylvania)
• Edward Kmett (S&P Capital IQ)
• Hans-Wolfgang Loidl (Heriot-Watt University)
• Trevor L. McDonell (Indiana University)
• Deian Stefan (UC San Diego and GitStar)
• Josef Svenningsson - chair (Chalmers University of Technology)