Many functions have to be written over and over again for different datatypes, either because datatypes change during the development of programs, or because functions with similar functionality are needed on different datatypes. Examples of such functions are pretty printers, debuggers, equality functions, unifiers, pattern matchers, rewriting functions, etc. Such functions are called polytypic functions. A polytypic function is a function that is defined by induction on the structure of user-defined datatypes. This paper extends a functional language (a subset of Haskell) with a construct for writing polytypic functions. The extended language type checks definitions of polytypic functions, and infers the types of all other expressions using an extension of Jones ' theories of qualified types and higher-order polymorphism. The semantics of the programs in the extended language is obtained by adding type arguments to functions in a dictionary passing style. Programs in the extended language are translated to Haskell. 1

PolyP extends a functional language (a subset of Haskell) with a construct for defining polytypic functions by induction on the structure of user-defined datatypes. Programs in the extended language are translated to Haskell. PolyLib contains powerful structured recursion operators like catamorphisms, maps and traversals, as well as polytypic versions of a number of standard functions from functional programming: sum, length, zip, (==), (6), etc. Both the specification of the library and a PolyP implementation are presented.

Abstract not found

Abstract. A nested datatype, also known as a non-regular datatype, is a parametrised datatype whose declaration involves different instances of the accompanying type parameters. Nested datatypes have been mostly ignored in functional programming until recently, but they are turning out to be both theoretically important and useful in practice. The aim of this paper is to suggest a functorial semantics for such datatypes, with an associated calculational theory that mirrors and extends the standard theory for regular datatypes. Though elegant and generic, the proposed approach appears more limited than one would like, and some of the limitations are discussed. 1

A polytypic function is a function that can be instantiated on many data types to obtain data type specific functionality. Examples of polytypic functions are the functions that can be derived in Haskell, such as show , read , and ` '. More advanced examples are functions for digital searching, pattern matching, unification, rewriting, and structure editing. For each of these problems, we not only have to define polytypic functionality, but also a type-indexed data type: a data type that is constructed in a generic way from an argument data type. For example, in the case of digital searching we have to define a search tree type by induction on the structure of the type of search keys. This paper shows how to define type-indexed data types, discusses several examples of type-indexed data types, and shows how to specialize type-indexed data types. The approach has been implemented in Generic Haskell, a generic programming extension of the functional language Haskell.

Abstract not found

A polytypic function definition is a function definition that is parametrised with a datatype. It embraces a class of algorithms. As an example we define a simple polytypic "crush" combinator that can be used to calculate polytypically. The ability to define functions polytypically adds another level of flexibility in the reusability of programming idioms and in the design of libraries of interoperable components.

Generic Haskell is an extension of Haskell that supports the construction of generic programs. These lecture notes discuss three advanced generic programming applications: generic dictionaries, compressing XML documents, and the zipper: a data structure used to represent a tree together with a subtree that is the focus of attention, where that focus may move left, right, up or down the tree. When describing and implementing these examples, we will encounter some advanced features of Generic Haskell, such as type-indexed data types, dependencies between and generic abstractions of generic functions, adjusting a generic function using a default case, and generic functions with a special case for a particular constructor.

Several generic programs for converting values from regular datatypes to some other format, together with their corresponding inverses, are constructed. Among the formats considered are shape plus contents, compact bit streams and pretty printed strings. The different data conversion programs are constructed using John Hughes' arrow combinators along with a proof that printing (from a regular datatype to another format) followed by parsing (from that format back to the regular datatype) is the identity. The printers and parsers are described in PolyP, a polytypic extension of the functional language Haskell.

Writing program generators involves the development of programs that manipulate representations of programs, thus offering unlimited possibliities for abstraction. Abstractions not expressable in typed languages can always be expressed as generators. For example generator mechanisms are implicit in the eq-types of Standard ML, and the deriving clauses of Haskel type classes, neither of which can be encoded within the language. While these mechanisms always generate well typed code, they are "hard coded" into the compiler. Our goal is to incorporate generator like abstraction mechanisms into programming languages, while ensuring that only well typed programs are executed. This can be accomplished by a generate and then type-check approach or an inference mechanism that guarantees that only well typed programs are generated. In this paper we investigate both possibilities. The problems associated with program generators include problems of "hygiene" and the type compatibility of the programs being generated. Naive approaches to typing generators have either been inflexible (giving rigid, invariant types to the meta-level expressions representing programs requiring every object term to have the same type) or undecidable (requiring dependent types with arbitrary equality theories on expression equality). We solve the hygiene problems by the use of syntactic closures and have approached the type problem in two ways. First, by using a two level system (a la Nielson and Nielson[9]) we are able to embed a meta-computation phase which associates invariant code types to object expressions, into a later phase which then indexes these code types with the object expression's type. This ensures that only well-typed programs reach the run-time phase. We guarantee that the meta-computation phase terminates by restricting its expressiveness by the use of catamorphisms as the exclusive mechanism to encode recursion. Second we introduce a theory of dependent types for two-level languages that has a useful, decidable theory due to the use of catamorphisms, rather than arbitrary recursion, in the expressions that may index dependent types. We show that this can give useful types to program generators which detect type problems in generated code at the compile-type of the generator. Third we show that by embedding second level type declarations as values in first level computations we are able to construct polytypic program generators, such as polymorphic equality and generic map using our theory.