Results 1 
5 of
5
Exploring the regular tree types
 In Types for Proofs and Programs
, 2004
"... Abstract. In this paper we use the Epigram language to define the universe of regular tree types—closed under empty, unit, sum, product and least fixpoint. We then present a generic decision procedure for Epigram’s inbuilt equality at each type, taking a complementary approach to that of Benke, Dyb ..."
Abstract

Cited by 21 (4 self)
 Add to MetaCart
(Show Context)
Abstract. In this paper we use the Epigram language to define the universe of regular tree types—closed under empty, unit, sum, product and least fixpoint. We then present a generic decision procedure for Epigram’s inbuilt equality at each type, taking a complementary approach to that of Benke, Dybjer and Jansson [7]. We also give a generic definition of map, taking our inspiration from Jansson and Jeuring [21]. Finally, we equip the regular universe with the partial derivative which can be interpreted functionally as Huet’s notion of ‘zipper’, as suggested by McBride in [27] and implemented (without the fixpoint case) in Generic Haskell by Hinze, Jeuring and Löh [18]. We aim to show through these examples that generic programming can be ordinary programming in a dependently typed language. 1
Chapter 6 Epigram Reloaded:
"... Abstract Epigram, a functional programming environment with dependent types, interacts with the programmer via an extensible high level language of programming constructs which elaborates incrementally into Epigram’s Type Theory, ETT, a rather spartan λcalculus with dependent types, playing the ro ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract Epigram, a functional programming environment with dependent types, interacts with the programmer via an extensible high level language of programming constructs which elaborates incrementally into Epigram’s Type Theory, ETT, a rather spartan λcalculus with dependent types, playing the rôle of a ‘core language’. We implement a standalone typechecker for ETT in Haskell, allowing us to reload existing libraries into the system safely without reelaboration. Rather than adopting a rewriting approach to computation, we use a glued representation of values, pairing firstorder syntax with a functional representation of its semantics, computed lazily. This approach separates βreduction from βηconversion. We consequently can not only allow the ηlaws for λabstractions and pairs, but also collapse each of the unit and empty types. Epigram2 [22, 5] is at the same time a functional programming language with dependent types and a typedriven, interactive program development system. Its type system is strong enough to express a wide range of program properties, from
Chapter 1 Epigram Reloaded:
"... Abstract Epigram, a functional programming environment with dependent types, interacts with the programmer via an extensible high level language of programming constructs which elaborates incrementally into Epigram’s Type Theory, ETT, a rather spartan λcalculus with dependent types, playing the rôl ..."
Abstract
 Add to MetaCart
(Show Context)
Abstract Epigram, a functional programming environment with dependent types, interacts with the programmer via an extensible high level language of programming constructs which elaborates incrementally into Epigram’s Type Theory, ETT, a rather spartan λcalculus with dependent types, playing the rôle of a ‘core language’. We implement a standalone typechecker for ETT in Haskell, allowing us to reload existing libraries into the system safely without reelaboration. Rather than adopting a rewriting approach to computation, we use a glued representation of values, pairing firstorder syntax with a functional representation of its semantics, computed lazily. This approach separates βreduction from βηconversion. We consequently can not only allow the ηlaws for λabstractions and pairs, but also collapse each of the unit and empty types. 1.1
1 Motivation Epigram: Practical Programming with Dependent Types
"... Find the type error in the following Haskell expression: if null xs then tail xs else xs You can’t, of course: this program is obviously nonsense unless you’re a typechecker. The trouble is that only certain computations make sense if the null xs test is True, whilst others make sense if it is False ..."
Abstract
 Add to MetaCart
(Show Context)
Find the type error in the following Haskell expression: if null xs then tail xs else xs You can’t, of course: this program is obviously nonsense unless you’re a typechecker. The trouble is that only certain computations make sense if the null xs test is True, whilst others make sense if it is False. However, as far as the type system is concerned, the type of the then branch is the type of the else branch is the type of the entire conditional. Statically, the test is irrelevant. Which is odd, because if the test really were irrelevant, we wouldn’t do it. Of course, tail [] doesn’t go wrong—welltyped programs don’t go wrong—so we’d better pick a different word for the way they do go. Abstraction and application, tupling and projection: these provide the ‘software engineering ’ superstructure for programs, and our familiar type systems ensure that these operations are used compatibly. However, sooner or later, most programs inspect data and make a choice—at that point our familiar type systems fall silent. They simply can’t talk about specific data. All this time, we