System FC with explicit kind equality

Weirich, Stephanie; Hsu, Justin; Eisenberg, Richard A.

doi:10.1145/2500365.2500599

Cited by 23 publications

(6 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Since GHC 8.0, Haskell allows dependency within type signatures [Weirich et al 2013], meaning that the straightforward left-to-right ordering of variables-even in a user-written type signature-might not be well-scoped. As a simple example, consider tr :: TypeRep (a :: k), where TypeRep :: ∀ k. k → Type allows runtime type representation and is part of GHC's standard library.…”

Section: A5 Implicit Generalisationmentioning

confidence: 99%

Seeking stability by being lazy and shallow: lazy and shallow instantiation is user friendly

Bottu

Eisenberg²

2021

Proceedings of the 14th ACM SIGPLAN International Symposium on Haskell

Self Cite

View full text Add to dashboard Cite

Designing a language feature often requires a choice between several, similarly expressive possibilities. Given that user studies are generally impractical, we propose using stability as a way of making such decisions. Stability is a measure of whether the meaning of a program alters under small, seemingly innocuous changes in the code (e.g., inlining).Directly motivated by a need to pin down a feature in GHC/Haskell, we apply this notion of stability to analyse four approaches to the instantiation of polymorphic types, concluding that the most stable approach is lazy (instantiate a polytype only when absolutely necessary) and shallow (instantiate only top-level type variables, not variables that appear after explicit arguments).

show abstract

Section: A5 Implicit Generalisationmentioning

confidence: 99%

Seeking stability by being lazy and shallow: lazy and shallow instantiation is user friendly

Bottu

Eisenberg²

2021

Proceedings of the 14th ACM SIGPLAN International Symposium on Haskell

Self Cite

View full text Add to dashboard Cite

show abstract

“…It would be interesting to explore a similar encoding of our work into an appropriate λ-calculus such as F ω with product types. Weirich et al [2013] study an extension to the core language (System FC) of the Glasgow Haskell Compiler (GHC) with a notion of kind equality proofs, in order to allow type-level computation in Haskell to refer to kind-level functions. Their development, being based on System FC, is designed to manipulate explicit type and kind coercions as part of the core language itself, which have a nontrivial structure (as required by the various type features and extensions of GHC), and so differs significantly from our work which is designed to keep type and kind conversion as implicit as possible.…”

Section: Related Workmentioning

confidence: 99%

Refinement kinds: type-safe programming with practical type-level computation

Caires

Toninho

2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

This work introduces the novel concept of kind refinement, which we develop in the context of an explicitly polymorphic ML-like language with type-level computation. Just as type refinements embed rich specifications by means of comprehension principles expressed by predicates over values in the type domain, kind refinements provide rich kind specifications by means of predicates over types in the kind domain. By leveraging our powerful refinement kind discipline, types in our language are not just used to statically classify program expressions and values, but also conveniently manipulated as tree-like data structures, with their kinds refined by logical constraints on such structures. Remarkably, the resulting typing and kinding disciplines allow for powerful forms of type reflection, ad-hoc polymorphism and type meta-programming, which are often found in modern software development, but not typically expressible in a type-safe manner in general purpose languages. We validate our approach both formally and pragmatically by establishing the standard meta-theoretical results of type safety and via a prototype implementation of a kind checker, type checker and interpreter for our language. = x @ The addField function takes a label l, a type t, a record type r that does not contain label l, and values of types t and r , respectively, returning a record of type addFieldType l t r .The type-level and term-level functions addFieldType and addField respectively illustrate some of the key insights of our type theory, namely the use of types and their refined kinds as specifications that can be manipulated as tree-like structures by programs in a fully type-safe way. For instance, the following judgment, expressing the correspondence between the term-level computation addField l t r x and the type-level computation addFieldType l t r , is derivable: l:Nm, t:Type, r :{s::Rec | l lab(s)}, x:t, :r ⊢ addField l t r x : addFieldType l t r An instance of this judgement yields:⊢ addField name String a e : Int "jack" a e = 20 : addFieldType name String a e : Int Noting that age : Int :: {s::Rec | name lab(s)} is derivable since name lab( age : Int ) is provable in the refinement logic, we have the following term and type-level evaluations:(addField name String a e : Int "jack" a e = 20 ) → * name = "jack"; age = 20 (addFieldType name String a e : Int ) ≡ name : String; age : Int

show abstract

“…Recent work has laid out a design for Haskell extended with dependent types [Eisenberg 2016;Gundry 2013;Weirich et al 2013 and there is ongoing work dedicated to implementing this theory [Xie and Eisenberg 2018]. 2 Dependent types are desirable for Haskell because they increase the ability to create abstractions.…”

Section: Extending Ghc With Dependent Typesmentioning

confidence: 99%

A Role for Dependent Types in Haskell (Extended version)

Weirich¹,

Choudhury²,

Voizard³

et al. 2019

Preprint

Self Cite

View full text Add to dashboard Cite

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 integrate roles with dependent type 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.

show abstract

System FC with explicit kind equality

Cited by 23 publications

References 29 publications

Seeking stability by being lazy and shallow: lazy and shallow instantiation is user friendly

Seeking stability by being lazy and shallow: lazy and shallow instantiation is user friendly

Refinement kinds: type-safe programming with practical type-level computation

A Role for Dependent Types in Haskell (Extended version)

Contact Info

Product

Resources

About