Results 1 
6 of
6
Decidable Bounded Quantification
 IN 21ST ACM SYMP. ON PRINCIPLES OF PROGRAMMING LANGUAGES
, 1994
"... The standard formulation of bounded quantification, system F , is difficult to work with and lacks important syntactic properties, such as decidability. More tractable variants have been studied, but those studied so far either exclude significant classes of useful programs or lack a compelling ..."
Abstract

Cited by 26 (3 self)
 Add to MetaCart
The standard formulation of bounded quantification, system F , is difficult to work with and lacks important syntactic properties, such as decidability. More tractable variants have been studied, but those studied so far either exclude significant classes of useful programs or lack a compelling semantics. We propose
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 16 (3 self)
 Add to MetaCart
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
I am not a number: I am a free variable
 In Haskell workshop
, 2004
"... In this paper, we show how to manipulate syntax with binding using a mixed representation of names for free variables (with respect to the task in hand) and de Bruijn indices [dB72] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmeticf ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
In this paper, we show how to manipulate syntax with binding using a mixed representation of names for free variables (with respect to the task in hand) and de Bruijn indices [dB72] for bound variables. By doing so, we retain the advantages of both representations: naming supports easy, arithmeticfree manipulation of terms; de Bruijn indices eliminate the need for αconversion. Further, we have ensure that not only the user but also the implementation need never deal with de Bruijn indices, except within key basic operations. Moreover, we give a representation for names which readily supports a power structure naturally reflecting the structure of the implementation. Name choice is safe and straightforward. Our technology combines easily with an approach to syntax manipulation inspired by Huet’s ‘zippers’[Hue97]. Without the technology in this paper, we could not have implemented Epigram [McB04]. Our example—constructing inductive elimination operators for datatype families—is but one of many where it proves invaluable. Prologue In conversation, we like to have names for the people we’re talking about. If we had to say things like ‘the person three to the left of me ’ rather than ‘Fred’, things would get complicated whenever anyone went to the lavatory. You don’t need to have formalized the strengthening property for Pure Type Systems [MP99] to appreciate this basic phenomenon of social interaction. It is in the company of strangers that more primitive pointingbased modes of reference acquire a useful rôle as a way of indicating unambiguously an individual with no socially agreed name. Even so, once a stranger enters the context of the conversation, he or she typically acquires a name. What this name is and who chooses it depends on the power relationships between those involved, as we learned in the playground at school. Moreover, if we are having a conversation about hypothetical individuals—say, Alice, Bob and Unscrupulous Charlie—we have a tendency to name them locally to the discussion. We do not worry about whether Unscrupulous Charlie might actually turn out to be called Shameless David whenever he turns up. That is, we exploit naming locally to assist the construction of explanations which apply to individuals regardless of what they are called. 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
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
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
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