Results 1  10
of
29
Strongly typed heterogeneous collections
 In Haskell ’04: Proceedings of the ACM SIGPLAN workshop on Haskell
, 2004
"... A heterogeneous collection is a datatype that is capable of storing data of different types, while providing operations for lookup, update, iteration, and others. There are various kinds of heterogeneous collections, differing in representation, invariants, and access operations. We describe HLIST ..."
Abstract

Cited by 56 (12 self)
 Add to MetaCart
A heterogeneous collection is a datatype that is capable of storing data of different types, while providing operations for lookup, update, iteration, and others. There are various kinds of heterogeneous collections, differing in representation, invariants, and access operations. We describe HLIST — a Haskell library for strongly typed heterogeneous collections including extensible records. We illustrate HLIST’s benefits in the context of typesafe database access in Haskell. The HLIST library relies on common extensions of Haskell 98. Our exploration raises interesting issues regarding Haskell’s type system, in particular, avoidance of overlapping instances, and reification of type equality and type unification.
Generic programming within dependently typed programming
 In Generic Programming, 2003. Proceedings of the IFIP TC2 Working Conference on Generic Programming, Schloss Dagstuhl
, 2003
"... Abstract We show how higher kinded generic programming can be represented faithfully within a dependently typed programming system. This development has been implemented using the Oleg system. The present work can be seen as evidence for our thesis that extensions of type systems can be done by prog ..."
Abstract

Cited by 52 (7 self)
 Add to MetaCart
Abstract We show how higher kinded generic programming can be represented faithfully within a dependently typed programming system. This development has been implemented using the Oleg system. The present work can be seen as evidence for our thesis that extensions of type systems can be done by programming within a dependently typed language, using data as codes for types. 1.
Datatypegeneric programming
 Spring School on DatatypeGeneric Programming, volume 4719 of Lecture Notes in Computer Science
"... Abstract. Generic programming aims to increase the flexibility of programming languages, by expanding the possibilities for parametrization — ideally, without also expanding the possibilities for uncaught errors. The term means different things to different people: parametric polymorphism, data abst ..."
Abstract

Cited by 48 (12 self)
 Add to MetaCart
Abstract. Generic programming aims to increase the flexibility of programming languages, by expanding the possibilities for parametrization — ideally, without also expanding the possibilities for uncaught errors. The term means different things to different people: parametric polymorphism, data abstraction, metaprogramming, and so on. We use it to mean polytypism, that is, parametrization by the shape of data structures rather than their contents. To avoid confusion with other uses, we have coined the qualified term datatypegeneric programming for this purpose. In these lecture notes, we expand on the definition of datatypegeneric programming, and present some examples of datatypegeneric programs. We also explore the connection with design patterns in objectoriented programming; in particular, we argue that certain design patterns are just higherorder datatypegeneric programs. 1
Typing XHTML Web Applications in ML
 In International Symposium on Practical Aspects of Declarative Languages (PADL’04), volume 3057 of LNCS
, 2004
"... In this paper, we present a type system for typing Web applications in SMLserver, an e#cient multithreaded Web server platform for Standard ML scriptlets. The type system guarantees that only conforming XHTML documents are sent to clients and that forms are used consistently and in a typesafe ..."
Abstract

Cited by 11 (1 self)
 Add to MetaCart
In this paper, we present a type system for typing Web applications in SMLserver, an e#cient multithreaded Web server platform for Standard ML scriptlets. The type system guarantees that only conforming XHTML documents are sent to clients and that forms are used consistently and in a typesafe way. The type system is encoded in the type system of Standard ML using socalled phantom types.
Why dependent types matter
 In preparation, http://www.epig.org/downloads/ydtm.pdf
, 2005
"... We exhibit the rationale behind the design of Epigram, a dependently typed programming language and interactive program development system, using refinements of a well known program—merge sort—as a running example. We discuss its relationship with other proposals to introduce aspects of dependent ty ..."
Abstract

Cited by 10 (2 self)
 Add to MetaCart
We exhibit the rationale behind the design of Epigram, a dependently typed programming language and interactive program development system, using refinements of a well known program—merge sort—as a running example. We discuss its relationship with other proposals to introduce aspects of dependent types into functional programming languages and sketch some topics for further work in this area. 1.
Clowns to the left of me, jokers to the right (pearl): dissecting data structures
 Proceedings of the 35th ACM SIGPLANSIGACT Symposium on Principles of Programming Languages
, 2008
"... This paper introduces a small but useful generalisation to the ‘derivative ’ operation on datatypes underlying Huet’s notion of ‘zipper ’ (Huet 1997; McBride 2001; Abbott et al. 2005b), giving a concrete representation to onehole contexts in data which is undergoing transformation. This operator, ‘ ..."
Abstract

Cited by 9 (0 self)
 Add to MetaCart
This paper introduces a small but useful generalisation to the ‘derivative ’ operation on datatypes underlying Huet’s notion of ‘zipper ’ (Huet 1997; McBride 2001; Abbott et al. 2005b), giving a concrete representation to onehole contexts in data which is undergoing transformation. This operator, ‘dissection’, turns a containerlike functor into a bifunctor representing a onehole context in which elements to the left of the hole are distinguished in type from elements to its right. I present dissection here as a generic program, albeit for polynomial functors only. The notion is certainly applicable more widely, but here I prefer to concentrate on its diverse applications. For a start, maplike operations over the functor and foldlike operations over the recursive data structure it induces can be expressed by tail recursion alone. Further, the derivative is readily recovered from the dissection. Indeed, it is the dissection structure which delivers Huet’s operations for navigating zippers. The original motivation for dissection was to define ‘division’, capturing the notion of leftmost hole, canonically distinguishing values with no elements from those with at least one. Division gives rise to an isomorphism corresponding to the remainder theorem in algebra. By way of a larger example, division and dissection are exploited to give a relatively efficient generic algorithm for abstracting all occurrences of one term from another in a firstorder syntax. The source code for the paper is available online 1 and compiles with recent extensions to the Glasgow Haskell Compiler.
Lightweight Invariants with Full Dependent Types
"... Dependent types allow a programmer to express invariant properties of functions, such as the relationship between the input and output lengths of a list. Several “lightweight” approaches to dependent types have been proposed for existing systems, such as Haskell’s Generalised Algebraic Data Types ..."
Abstract

Cited by 3 (2 self)
 Add to MetaCart
Dependent types allow a programmer to express invariant properties of functions, such as the relationship between the input and output lengths of a list. Several “lightweight” approaches to dependent types have been proposed for existing systems, such as Haskell’s Generalised Algebraic Data Types or Type Families. Such approaches are lightweight in the sense that they require minimal modifications to existing systems. However, while these extensions are apparently simple, we find that we often run into limitations fairly quickly. In this paper we will explore these limitations, and show that a full dependent type system allows more straightforward implementation of simple invariants without restricting expressivity.
Simply Easy! An Implementation of a Dependently Typed Lambda Calculus
, 2007
"... We present an implementation in Haskell of a dependentlytyped lambda calculus that can be used as the core of a programming language. We show that a dependentlytyped lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
We present an implementation in Haskell of a dependentlytyped lambda calculus that can be used as the core of a programming language. We show that a dependentlytyped lambda calculus is no more difficult to implement than other typed lambda calculi. In fact, our implementation is almost as easy as an implementation of the simply typed lambda calculus, which we emphasize by discussing the modifications necessary to go from one to the other. We explain how to add data types and write simple programs in the core language, and discuss the steps necessary to build a fullfledged programming language on top of our simple core.
Phase distinctions in the compilation of Epigram
, 2005
"... Abstract. It is commonly believed that in dependently typed programming languages, the blurring of the distinction between types and values means that no type erasure is possible at runtime. In this paper, however, we propose an alternative phase distinction. Rather than distinguishing types and va ..."
Abstract

Cited by 1 (1 self)
 Add to MetaCart
Abstract. It is commonly believed that in dependently typed programming languages, the blurring of the distinction between types and values means that no type erasure is possible at runtime. In this paper, however, we propose an alternative phase distinction. Rather than distinguishing types and values in the compilation of EPIGRAM, we distinguish compiletime and runtime evaluation, and show by a series of program transformations that values which are not required at runtime can be erased. 1