A role for dependent types in Haskell

Abstract

Modern Haskell supports zero-cost coercions, a mechanism where types that share the same run-time representation may be freely converted between. To make sure such conversions are safe and desirable, this feature relies on a mechanism of roles to prohibit invalid coercions. In this work, we show how to incorporate roles into dependent types systems and prove, using the Coq proof assistant, that the resulting system is sound. We have designed this work as a foundation for the addition of dependent types to the Glasgow Haskell Compiler, but we also expect that it will be of use to designers of other dependently-typed languages who might want to adopt Haskell's safe coercions feature. A newtype in Haskell 1 is a user-defined algebraic datatype with exactly one constructor; that constructor takes exactly one argument. Here is an example: newtype HTML = MkHTML StringThis declaration creates a generative abstraction; the HTML type is new in the sense that it is not equal to any existing type. We call the argument type (String) the representation type. Because a newtype is isomorphic to its representation type, the Haskell compiler uses the same in-memory format for values of these types. Thus, creating a value of a newtype (i.e., calling MkHTML) is free at runtime, as is unpacking it (i.e., using a pattern-match).However, the Haskell type checker treats the newtype and its representation type as wholly distinct, meaning programmers cannot accidentally confuse HTML objects with String objects. We thus call newtypes a zero-cost abstraction: a convenient compile-time distinction with no cost 1 In this paper, we use łHaskellž to refer to the language implemented by the Glasgow Haskell Compiler (GHC), version 8.6.

Idris 2: Quantitative Type Theory in Practice

“…Idris 1 uses a whole program analysis [42], partly inspired by earlier work on Erasure Pure Type Systems [31] to determine which arguments can be erased, which works well in practice but doesn't allow a programmer to require specific arguments to be erased, and means that separate compilation is difficult. The problem of what to erase also exists in Haskell to some extent, even without full dependent types, when implementing zero cost coercions [46]. Our experience of the 0 multiplicity of QTT so far is that it provides the cleanest solution to the erasure problem, although we no longer infer which other arguments can be erased.…”

Label dependent lambda calculus and gradual typing

“…Dependently-typed programming is on the rise. What started as a foundation for mathematics [Coquand and Huet 1988;Martin-Löf 1984] gave rise to powerful interactive verification tools [Bertot and Castéran 2004;Norell 2008] and is now influencing programming languages like Idris [Brady 2013], Haskell [Weirich et al 2019], andTypeScript [typescript handbook 2021]. The trademark of dependent type theories is the dependent function type, where the type of the return value is calculated from the run-time value of the argument.…”

Strong functional pearl: Harper’s regular-expression matcher in Cedille

“…Pure FP seems to creep closer year by year to type theory, with the recent advent of dependent Haskell [Weirich et al 2019[Weirich et al , 2017, liquid types in Haskell [Vazou et al 2014], hasochism [Lindley and McBride 2013], refinement and dependent types in Racket [Kent 2017], and more. A conceptual midway point between type theory and pure FPÐone not generally pursued in the works just citedÐ is strong functional programming as proposed by Turner [Turner 1995].…”