Levity Polymorphism

Parametric polymorphism is one of the linchpins of modern typed programming, but it comes with a real performance penalty. We describe this penalty; offer a principled way to reason about it (kinds as calling conventions); and propose levity polymorphism. This new form of polymorphism allows abstractions over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Levity polymorphism has created new opportunities in Haskell, including the ability to generalize nearly half of the type classes in GHC\u27s standard library

Levity Polymorphism (extended version)

Parametric polymorphism is one of the lynchpins of modern typed programming. A function that can work seamlessly over a variety of types simplifies code, helps to avoid errors introduced through duplication, and and is easy to maintain. However, polymorphism comes at a very real cost, one that each language with support for polymorphism has paid in different ways. This paper describes this cost, proposes a theoretically simple way to reason about the cost—that kinds, not types, are calling conventions—and details one approach to dealing with polymorphism that works in the context of a language, Haskell, that prizes both efficiency and a principled type system. This approach, levity polymorphism, allows the user to abstract over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Lev- ity polymorphism has opened up surprising new opportunities for library design in Haskell

Levity Polymorphism (extended version)

Parametric polymorphism is one of the lynchpins of modern typed programming. A function that can work seamlessly over a variety of types simplifies code, helps to avoid errors introduced through duplication, and and is easy to maintain. However, polymorphism comes at a very real cost, one that each language with support for polymorphism has paid in different ways. This paper describes this cost, proposes a theoretically simple way to reason about the cost—that kinds, not types, are calling conventions—and details one approach to dealing with polymorphism that works in the context of a language, Haskell, that prizes both efficiency and a principled type system. This approach, levity polymorphism, allows the user to abstract over calling conventions; we detail and verify restrictions that are necessary in order to compile levity-polymorphic functions. Lev- ity polymorphism has opened up surprising new opportunities for library design in Haskell

An Overabundance of Equality: Implementing Kind Equalities into Haskell

Haskell, as embodied by version 7.10.1 of the Glasgow Haskell Compiler (GHC), supports reasoning about equality among types, via generalized algebraic datatypes (GADTs) and type families. However, these features are not available among the kinds that clas- sify the types. Motivated by a concrete example of how kind equali- ties can help programmers today, this paper presents the challenges and solutions encountered in integrating kind equalities into GHC, an industrial-strength compiler. The challenges addressed here all surround the many notions of type equality that exist in GHC to- day, and in particular around GHC’s role mechanism. These many different relations on types complicate the theory considerably An update of GHC supporting reasoning about kind equalities is a key part of this work

An Overabundance of Equality: Implementing Kind Equalities into Haskell

Haskell, as embodied by version 7.10.1 of the Glasgow Haskell Compiler (GHC), supports reasoning about equality among types, via generalized algebraic datatypes (GADTs) and type families. However, these features are not available among the kinds that clas- sify the types. Motivated by a concrete example of how kind equali- ties can help programmers today, this paper presents the challenges and solutions encountered in integrating kind equalities into GHC, an industrial-strength compiler. The challenges addressed here all surround the many notions of type equality that exist in GHC to- day, and in particular around GHC’s role mechanism. These many different relations on types complicate the theory considerably An update of GHC supporting reasoning about kind equalities is a key part of this work

Linear Haskell: practical linearity in a higher-order polymorphic language

Linear type systems have a long and storied history, but not a clear path forward to integrate with existing languages such as OCaml or Haskell. In this paper, we study a linear type system designed with two crucial properties in mind: backwards-compatibility and code reuse across linear and non-linear users of a library. Only then can the benefits of linear types permeate conventional functional programming. Rather than bifurcate types into linear and non-linear counterparts, we instead attach linearity to function arrows. Linear functions can receive inputs from linearly-bound values, but can also operate over unrestricted, regular values. To demonstrate the efficacy of our linear type system - both how easy it can be integrated in an existing language implementation and how streamlined it makes it to write programs with linear types - we implemented our type system in GHC, the leading Haskell compiler, and demonstrate two kinds of applications of linear types: mutable data with pure interfaces; and enforcing protocols in I/O-performing functions

A Specification for Dependent Types in Haskell

We propose a core semantics for Dependent Haskell, an extension of Haskell with full-spectrum dependent types. Our semantics consists of two related languages. The first is a Curry-style dependently-typed language with nontermination, irrelevant arguments, and equality abstraction. The second, inspired by the Glasgow Haskell Compiler’s core language FC, is its explicitly-typed analogue, suitable for implementation in GHC. All of our results -- chiefly, type safety, along with theorems that relate these two languages -- have been formalized using the Coq proof assistant. Because our work is backwards compatible with Haskell, our type safety proof holds in the presence of nonterminating computation. However, unlike other full-spectrum dependently-typed languages, such as Coq, Agda or Idris, because of this nontermination, Haskell’s term language does not correspond to a consistent logic

A Specification for Dependent Types in Haskell

We propose a core semantics for Dependent Haskell, an extension of Haskell with full-spectrum dependent types. Our semantics consists of two related languages. The first is a Curry-style dependently-typed language with nontermination, irrelevant arguments, and equality abstraction. The second, inspired by the Glasgow Haskell Compiler’s core language FC, is its explicitly-typed analogue, suitable for implementation in GHC. All of our results -- chiefly, type safety, along with theorems that relate these two languages -- have been formalized using the Coq proof assistant. Because our work is backwards compatible with Haskell, our type safety proof holds in the presence of nonterminating computation. However, unlike other full-spectrum dependently-typed languages, such as Coq, Agda or Idris, because of this nontermination, Haskell’s term language does not correspond to a consistent logic