Results 1  10
of
18
Generative Type Abstraction and Typelevel Computation (Extended Version)
"... Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this wellestablished feature is in tension with the nonparametric features of newer type systems, s ..."
Abstract

Cited by 15 (9 self)
 Add to MetaCart
Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this wellestablished feature is in tension with the nonparametric features of newer type systems, such as indexed type families and GADTs. In this paper we solve the problem by using kinds to distinguish between parametric and nonparametric contexts. The result is directly applicable to Haskell, which is rapidly developing support for typelevel computation, but the same issues should arise whenever generativity and nonparametric features are combined.
Modularising inductive families
 In Jaakko Järvi and ShinCheng Mu, editors, Workshop on Generic Programming, WGP’11
, 2011
"... Dependently typed programmers are encouraged to use inductive families to integrate constraints with data construction. Different constraints are used in different contexts, leading to different versions of datatypes for the same data structure. For example, sequences might be constrained by length ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
Dependently typed programmers are encouraged to use inductive families to integrate constraints with data construction. Different constraints are used in different contexts, leading to different versions of datatypes for the same data structure. For example, sequences might be constrained by length or by an ordering on elements, giving rise to different datatypes “vectors ” and “sorted lists ” for the same underlying data structure of sequences. Modular implementation of common operations for these structurally similar datatypes has been a longstanding problem. We propose a datatypegeneric solution, in which we axiomatise a family of isomorphisms between datatypes and their more refined versions as datatype refinements, and show that McBride’s ornaments can be translated into such refinements. With the ornamentinduced refinements, relevant properties of the operations can be separately proven for each constraint, and after the programmer selects several constraints to impose on a basic datatype and synthesises a new datatype incorporating those constraints, the operations can be routinely upgraded to work with the synthesised datatype. 1
When is a type refinement an inductive type
 In FOSSACS, volume 6604 of Lecture Notes in Computer Science
, 2011
"... Abstract. Dependently typed programming languages allow sophisticated properties of data to be expressed within the type system. Of particular use in dependently typed programming are indexed types that refine data by computationally useful information. For example, the Nindexed type of vectors ref ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
Abstract. Dependently typed programming languages allow sophisticated properties of data to be expressed within the type system. Of particular use in dependently typed programming are indexed types that refine data by computationally useful information. For example, the Nindexed type of vectors refines lists by their lengths. Other data types may be refined in similar ways, but programmers must produce purposespecific refinements on an ad hoc basis, developers must anticipate which refinements to include in libraries, and implementations often store redundant information about data and their refinements. This paper shows how to generically derive inductive characterisations of refinements of inductive types, and argues that these characterisations can alleviate some of the aforementioned difficulties associated with ad hoc refinements. These characterisations also ensure that standard techniques for programming with and reasoning about inductive types are applicable to refinements, and that refinements can themselves be further refined. 1
Outrageous but meaningful coincidences: Dependent typesafe syntax and evaluation
 In ACM SIGPLAN Workshop on Genetic Programming (WGP’10
, 2010
"... Tagless interpreters for welltyped terms in some object language are a standard example of the power and benefit of precise indexing in types, whether with dependent types, or generalized algebraic datatypes. The key is to reflect object language types as indices (however they may be constituted) f ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
Tagless interpreters for welltyped terms in some object language are a standard example of the power and benefit of precise indexing in types, whether with dependent types, or generalized algebraic datatypes. The key is to reflect object language types as indices (however they may be constituted) for the term datatype in the host language, so that host type coincidence ensures object type coincidence. Whilst this technique is widespread for simply typed object languages, dependent types have proved a tougher nut with nontrivial computation in type equality. In their typesafe representations, Danielsson [2006] and Chapman [2009] succeed in capturing the equality rules, but at the cost of representing equality derivations explicitly within terms. This article delivers a typesafe representation for a dependently typed object language, dubbed KIPLING, whose computational type equality just appropriates that of its host, Agda. The KIPLING interpreter example is not merely de rigeur— it is key to the construction. At the heart of the technique is that key component of generic programming, the universe. 1.
Modular TypeSafety Proofs in Agda
"... Methods for reusing code are widespread and well researched, but methods for reusing proofs are still emerging. We consider the use of dependent types for this purpose, introducing a modular approach for composing mechanized proofs. We show that common techniques for abstracting algorithms over data ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
Methods for reusing code are widespread and well researched, but methods for reusing proofs are still emerging. We consider the use of dependent types for this purpose, introducing a modular approach for composing mechanized proofs. We show that common techniques for abstracting algorithms over data structures naturally translate to abstractions over proofs. We introduce a language composed of a series of smaller language components, each defined as functors, and tie them together by taking the fixed point of their sum [Malcom, 1990]. We then give proofs of type preservation for each language component and show how to compose these proofs into a proof for the entire language, again by taking the fixed point of a sum of functors.
A Categorical Treatment of Ornaments
"... Abstract—Ornaments aim at taming the multiplication of specialpurpose datatypes in dependently typed programming languages. In type theory, purpose is logic. By presenting datatypes as the combination of a structure and a logic, ornaments relate these specialpurpose datatypes through their common ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Abstract—Ornaments aim at taming the multiplication of specialpurpose datatypes in dependently typed programming languages. In type theory, purpose is logic. By presenting datatypes as the combination of a structure and a logic, ornaments relate these specialpurpose datatypes through their common structure. In the original presentation, the concept of ornament was introduced concretely for an example universe of inductive families in type theory, but it was clear that the notion was more general. This paper digs out the abstract notion of ornaments in the form of a categorical model. As a necessary first step, we abstract the universe of datatypes using the theory of polynomial functors. We are then able to characterise ornaments as cartesian morphisms between polynomial functors. We thus gain access to powerful mathematical tools that shall help us understand and develop ornaments. We shall also illustrate the adequacy of our model. Firstly, we rephrase the standard ornamental constructions into our framework. Thanks to its conciseness, we gain a deeper understanding of the structures at play. Secondly, we develop new ornamental constructions, by translating categorical structures into type theoretic artefacts.
Generative Type Abstraction and Typelevel Computation
"... Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this wellestablished feature is in tension with the nonparametric features of newer type systems, s ..."
Abstract
 Add to MetaCart
Modular languages support generative type abstraction, ensuring that an abstract type is distinct from its representation, except inside the implementation where the two are synonymous. We show that this wellestablished feature is in tension with the nonparametric features of newer type systems, such as indexed type families and GADTs. In this paper we solve the problem by using kinds to distinguish between parametric and nonparametric contexts. The result is directly applicable to Haskell, which is rapidly developing support for typelevel computation, but the same issues should arise whenever generativity and nonparametric features are combined. 1.
A Syntactical Approach to Weak ωGroupoids
"... Abstract—When moving to a Type Theory without proof irrelevance the notion of a setoid has to be generalized to the notion of a weak ωgroupoid. As a first step in this direction we study the formalisation of weak ωgroupoids in Type Theory. This is motivated by Voevodsky’s proposal of univalent typ ..."
Abstract
 Add to MetaCart
Abstract—When moving to a Type Theory without proof irrelevance the notion of a setoid has to be generalized to the notion of a weak ωgroupoid. As a first step in this direction we study the formalisation of weak ωgroupoids in Type Theory. This is motivated by Voevodsky’s proposal of univalent type theory which is incompatible with proofirrelevance and the results by Lumsdaine and Garner/van de Berg showing that the standard eliminator for equality gives rise to a weak ωgroupoid.
Research Paper Modularising Inductive Families Progress in Informatics, No.1 (2013.3)
"... Dependently typed programmers are encouraged to use inductive families to integrate constraints with data construction. Different constraints are used in different contexts, leading to different versions of datatypes for the same data structure. For example, sequences might be constrained by length ..."
Abstract
 Add to MetaCart
Dependently typed programmers are encouraged to use inductive families to integrate constraints with data construction. Different constraints are used in different contexts, leading to different versions of datatypes for the same data structure. For example, sequences might be constrained by length or by an ordering on elements, giving rise to different datatypes “vectors ” and “sorted lists ” for the same underlying data structure of sequences. Modular implementation of common operations for these structurally similar datatypes has been a longstanding problem. We propose a datatypegeneric solution, in which we axiomatise a family of isomorphisms between datatypes and their more refined versions as datatype refinements, and show that McBride’s ornaments can be translated into such refinements. With the ornamentinduced refinements, relevant properties of the operations can be separately proven for each constraint, and after the programmer selects several constraints to impose on a basic datatype and synthesises a new datatype incorporating those constraints, the operations can be routinely upgraded to work with the synthesised datatype.
Datatype ornamentation and the Dutch National Flag problem
, 2011
"... In his seminal book A Discipline of Programming [3], one of the concluding remarks made by Dijkstra was: [...] that it does not suffice to design a mechanism of which we hope that it will meet its requirements, but that we must design it in such a form that we can convince ourselves — and anyone els ..."
Abstract
 Add to MetaCart
In his seminal book A Discipline of Programming [3], one of the concluding remarks made by Dijkstra was: [...] that it does not suffice to design a mechanism of which we hope that it will meet its requirements, but that we must design it in such a form that we can convince ourselves — and anyone else for that matter — that it will, indeed, meet its requirements. And, therefore, instead of first designing the program and then trying to prove its correctness, we develop correctness proof and program hand in hand. (In actual fact, the correctness proof is developed slightly ahead of the program: after having chosen the form of the correctness proof we make the program so that it satisfies the proof’s requirements.) Dijkstra used the guarded command language for programming and predicate logic for reasoning, relating them by the weakest precondition semantics. The separation of programming language and reasoning language forced him to make the distinction between programs and proofs, and talk indirectly about a program