Results 1 
9 of
9
Nested datatypes
 In MPC’98, volume 1422 of LNCS
, 1998
"... Abstract. A nested datatype, also known as a nonregular 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 th ..."
Abstract

Cited by 90 (6 self)
 Add to MetaCart
(Show Context)
Abstract. A nested datatype, also known as a nonregular 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
Universal regular path queries
 HigherOrder and Symbolic Computation
, 2003
"... Given are a directed edgelabelled graph G with a distinguished node n0, and a regular expression P which may contain variables. We wish to compute all substitutions φ (of symbols for variables), together with all nodes n such that all paths n0 → n are in φ(P). We derive an algorithm for this proble ..."
Abstract

Cited by 19 (1 self)
 Add to MetaCart
Given are a directed edgelabelled graph G with a distinguished node n0, and a regular expression P which may contain variables. We wish to compute all substitutions φ (of symbols for variables), together with all nodes n such that all paths n0 → n are in φ(P). We derive an algorithm for this problem using relational algebra, and show how it may be implemented in Prolog. The motivation for the problem derives from a declarative framework for specifying compiler optimisations. 1 Bob Paige and IFIP WG 2.1 Bob Paige was a longstanding member of IFIP Working Group 2.1 on Algorithmic Languages and Calculi. In recent years, the main aim of this group has been to investigate the derivation of algorithms from specifications by program transformation. Already in the mideighties, Bob was way ahead of the pack: instead of applying transformational techniques to wellworn examples, he was applying his theories of program transformation to new problems, and discovering new algorithms [16, 48, 52]. The secret of his success lay partly in his insistence on the study of general algorithm design strategies (in particular
A Generic Program for Sequential Decision Processes
 Programming Languages: Implementations, Logics, and Programs
, 1995
"... This paper is an attempt to persuade you of my viewpoint by presenting a novel generic program for a certain class of optimisation problems, named sequential decision processes. This class was originally identified by Richard Bellman in his pioneering work on dynamic programming [4]. It is a perfect ..."
Abstract

Cited by 13 (2 self)
 Add to MetaCart
(Show Context)
This paper is an attempt to persuade you of my viewpoint by presenting a novel generic program for a certain class of optimisation problems, named sequential decision processes. This class was originally identified by Richard Bellman in his pioneering work on dynamic programming [4]. It is a perfect example of a class of problems which are very much alike, but which has until now escaped solution by a single program. Those readers who have followed some of the work that Richard Bird and I have been doing over the last five years [6, 7] will recognise many individual examples: all of these have now been unified. The point of this observation is that even when you are on the lookout for generic programs, it can take a rather long time to discover them. The presentation below will follow that earlier work, by referring to the calculus of relations and the relational theory of data types. I shall however attempt to be light on the formalism, as I do not regard it as essential to the main thesis of this paper. Undoubtedly there are other (perhaps more convenient) notations in which the same ideas could be developed. This paper does assume some degree of familiarity with a lazy functional programming language such as Haskell, Hope, Miranda
Container Types Categorically
, 2000
"... A program derivation is said to be polytypic if some of its parameters are data types. Often these data types are container types, whose elements store data. Polytypic program derivations necessitate a general, noninductive definition of `container (data) type'. Here we propose such a definiti ..."
Abstract

Cited by 13 (0 self)
 Add to MetaCart
A program derivation is said to be polytypic if some of its parameters are data types. Often these data types are container types, whose elements store data. Polytypic program derivations necessitate a general, noninductive definition of `container (data) type'. Here we propose such a definition: a container type is a relator that has membership. It is shown how this definition implies various other properties that are shared by all container types. In particular, all container types have a unique strength, and all natural transformations between container types are strong. Capsule Review Progress in a scientific dicipline is readily equated with an increase in the volume of knowledge, but the true milestones are formed by the introduction of solid, precise and usable definitions. Here you will find the first generic (`polytypic') definition of the notion of `container type', a definition that is remarkably simple and suitable for formal generic proofs (as is amply illustrated in t...
What is a Data Type?
, 1996
"... A program derivation is said to be polytypic if some of its parameters are data types. Polytypic program derivations necessitate a general, noninductive definition of `data type'. Here we propose such a definition: a data type is a relator that has membership. It is shown how this definition i ..."
Abstract

Cited by 4 (1 self)
 Add to MetaCart
(Show Context)
A program derivation is said to be polytypic if some of its parameters are data types. Polytypic program derivations necessitate a general, noninductive definition of `data type'. Here we propose such a definition: a data type is a relator that has membership. It is shown how this definition implies various other properties that are shared by all data types. In particular, all data types have a unique strength, and all natural transformations between data types are strong. 1 Introduction What is a data type? It is easy to list a number of examples: pairs, lists, bags, finite sets, possibly infinite sets, function spaces . . . but such a list of examples hardly makes a definition. The obvious formalisation is a definition that builds up the class of data types inductively; such an inductive definition, however, leads to cumbersome proofs if we want to prove a property of all data types. Here we aim to give a noninductive characterisation, defining a data type as a mathematical object...
An Exercise in Polytypic Program Derivation: repmin
, 1996
"... A program derivation is said to be polytypic if some of its parameters are data types. The repmin problem is to replace all elements of a tree of numbers by the minimum element, making only a single pass over the original tree. Here we present a polytypic derivation for that problem. The derivation ..."
Abstract

Cited by 3 (0 self)
 Add to MetaCart
A program derivation is said to be polytypic if some of its parameters are data types. The repmin problem is to replace all elements of a tree of numbers by the minimum element, making only a single pass over the original tree. Here we present a polytypic derivation for that problem. The derivation has an unusual feature: when interpreted in the category of relations, the resulting program is the wellknown cyclic logic program, and when interpreted in the category of functions, it is the wellknown higherorder functional solution. 1 Motivation Suppose I were to show you a derivation of a shortest path algorithm, and my whole presentation was in terms of numbers, addition and minimum. Undoubtedly some of you would get up and point out that by abstracting over the operations and recording their algebraic properties, I could have derived a whole class of algorithms instead of one particular program. Indeed, such abstraction over operations is now commonly accepted as one of the hallmar...
Polytypism and Polytypic Unification
, 1995
"... This report describes what polytypic programming is, a new system for writing polytypic functions, and a number of useful example functions including generalised versions of map, zip and a specific lazy array based unification algorithm. Sammanfattning Denna rapport beskriver hur man med ett program ..."
Abstract
 Add to MetaCart
(Show Context)
This report describes what polytypic programming is, a new system for writing polytypic functions, and a number of useful example functions including generalised versions of map, zip and a specific lazy array based unification algorithm. Sammanfattning Denna rapport beskriver hur man med ett programsystem automatiskt kan generera funktioner som fungerar fr alla trdtyper och detta systems tillmpning p ett antal anvndbara funktioner som map, zip och en speciell unifieringsalgoritm baserad p lata flt. 2 Polytypism and polytypic unification 1 Introduction 3 1.1 Background 3 1.2 Preliminaries and notation 4 1.3 Overview 4 2 Polytypism 5 2.1 Map 5 2.2 Cata 5 2.3 Functors 7 3 Basic polytypic functions 10 3.1 Predefined functions and types 10 3.1.1 Products 10 3.1.2 Sums 11 3.2 Notation 11 3.3 Object and arrow 12 3.4 In and out 13 3.5 Map 14 3.6 Cata 15 3.7 Ana 16 3.8 Hylo 16 3.9 Flatten 17 3.10 Partial functions 18 3.11 Zip 19 4 Program construction combinators 20 4.1 A combinator ...
A Class of Graph Algorithms
, 1996
"... Several graph problems are shown to be instances of the abstract problem of selecting representative elements from a closuregenerated set. These are the singlesource minimum paths problem, the reachability set of a given vertex, and the construction of rooted trees. Algorithms to compute such ..."
Abstract
 Add to MetaCart
Several graph problems are shown to be instances of the abstract problem of selecting representative elements from a closuregenerated set. These are the singlesource minimum paths problem, the reachability set of a given vertex, and the construction of rooted trees. Algorithms to compute such representatives are derived from the specification of the general problem. Instances of the algorithms include Dijkstra's minimum paths algorithm, and depthfirst/breadthfirst graph traversals. A relational calculus for algorithms derivation is used as algebraic framework. This calculus, of a pointfree reasoning character, is extended with categorical points to allow a clearer phrasing and manipulation of some algorithmic expressions. Pointwise reasoning can thus be naturally carried out within the extended calculus.