Pattern matching and dta abstraction are important concepts in designing programs, but they do not it well together. Pattern matching depend on making public a free data type mpresentaiion, while data abstraction depends on hiding the repreentaiion. This paper proposes the vdws mechanism at a means of reconc'dlng this conflict. A view allows any type to be viewed at a free data type, thus combining the clarity of pattern matching with the eiclency of data abstraction.

Not to be reproduced

Functional programming is a good idea, but we haven’t got it quite right yet. What we have been doing up to now is weak (or partial) functional programming. What we should be doing is strong (or total) functional programming- in which all computations terminate. We propose an elementary discipline of strong functional programming. A key feature of the discipline is that we introduce a type distinction between data, which is known to be finite, and codata, which is (potentially) infinite. 1 What is Functional Programming? It is widely agreed that functional programming languages make excellent introductory teaching vehicles for the basic concepts of computing. The wide range of topics covered in this symposium is evidence for that. But what is functional programming? Well, it is programming with functions, that much seems clear. But this really is not specific enough. The methods of denotational semantics show us

. This paper expands upon work begun in the author's [Tho89], in building a logic for the Miranda functional programming language. After summarising the work in that paper, a translation of Miranda definitions into logical formulas is presented, and illustrated by means of examples. This work expands upon [Tho89] in giving a complete treatment of sequences of equations, and by examining how to translate the local definitions introduced by where clauses. The status of the logic is then examined, and it is argued that the logic extends a natural operational semantics of Miranda, given by the translations of definitions into conditional equations. Finally it is shown how the logic can be implemented in the Isabelle proof tool. 1. Introduction `Functional programming languages are the best hope for formally-verified programming ' is article of faith for many. That it remains an article of faith, rather than a fact is because of the lack of any experimental evidence. In this paper we conti...

I/O mechanisms are needed if functional languages are to be suitable for general purpose programming and several implementations exist. But little is known about semantic methods for specifying and proving properties of lazy functional programs engaged in I/O. As a step towards formal methods of reasoning about realistic I/O we investigate three widely implemented mechanisms in the setting of teletype I/O: synchronised-stream (primitive in Haskell), continuationpassing (derived in Haskell) and Landin-stream I/O (where programs map an input stream to an output stream of characters) . Using methods from Milner's CCS we give a labelled transition semantics for the three mechanisms. We adopt bisimulation equivalence as equality on programs engaged in I/O and give functions to map between the three kinds of I/O. The main result is the first formal proof of semantic equivalence of the three mechanisms, generalising an informal argument of the Haskell committee. 1 Introduction and motivation...

Abstract. Many algorithms use concrete data types with some additional invariants. The set of values satisfying the invariants is often a set of representatives for the equivalence classes of some equational theory. For instance, a sorted list is a particular representative wrt commutativity. Theories like associativity, neutral element, idempotence, etc. are also very common. Now, when one wants to combine various invariants, it may be difficult to find the suitable representatives and to efficiently implement the invariants. The preservation of invariants throughout the whole program is even more difficult and error prone. Classically, the programmer solves this problem using a combination of two techniques: the definition of appropriate construction functions for the representatives and the consistent usage of these functions ensured via compiler data type for the representatives; unfortunately, pattern matching on representatives is lost. A more appealing alternative is to define a concrete data type with private constructors so that both compiler verification and pattern matching on representatives are granted. In this paper, we detail the notion of private data type and study the existence of construction functions. We also describe a prototype, called Moca, that addresses the entire problem of defining concrete data types with invariants: it generates efficient construction functions for the combination of common invariants and builds representatives that belong to a concrete data type with private constructors. 1

The functional programming language Haskell is examined from the point of view of proving programs correct. Particular features explored include the data type definition facilities, classes, the behaviour of patterns and guards and the monad approach to IO in the Glasgow Haskell compiler. 1 Introduction Haskell [Hudak et al., 1992, Hudak and Fasel, 1992] is a lazy functional programming language which is likely to become a de facto as well as a de jure standard academically and commercially. It is often said that a crucial part of the appeal of functional languages is the ease with which proofs concerning functional programs can be written. It is also widely accepted that if proof is to be taken seriously, it needs to be formalised, and to be checked by machine 1 . The aim of this paper is to initiate discussion on the form that a logic for Haskell might take. It is based to some degree on the author's previous work on devising a logic for Miranda, [Thompson, 1989], which in turn b...

this paper, we sketch the definition theory for a nonstrict positive free logic in which there is exactly one error object err to which all terms without existential import can refer. Having exactly one error object identifies nontermination and all run-time errors. This is most natural in languages such as Miranda and haskell in which execution is aborted immediately when an error is raised [16]. By using a free logic, we are able to state the axioms of a mathematical theory without cluttering the axiomatization with error conditions, as would be required using restricted quantification in standard logic. For example, Peano's axiom:

A relative specification is a collection of laws relating the behaviour of a required new program to that of one or more existing programs. A two stage method for transforming such relative specifications into effective functional programs is described and illustrated. The inversion stage re-arranges the specifying laws to obtain a collection of partial definitions for each unknown function, typically involving non-deterministic operators. The subsequent fusion stage combines each set of partial definitions into a single complete definition, thereby eliminating non-deterministic operators. Keywords: semantics and reasoning about programs, program transformations, specifications. 1 Introduction The first assumption of this paper is a preference for mathematical precision in the development of computer programs. Ideal program development begins with a formal specification of required behaviour, and proceeds by way of conjectures, laws, proofs, transformations, calculi and the like unti...

This paper describes our experience in formalising arguments about the Miranda functional programming language in Isabelle. After explaining some of the problems of reasoning about Miranda, we explain our two different approaches to encoding Miranda in Isabelle. We conclude by discussing some shorter examples and a case study of reasoning about hardware. Miranda 1 [Turner, 1990, Thompson, 1995b] is a modern functional programming language, allowing type polymorphism and higher-order functions in a similar way to ML[Milner et al., 1990]. It differs from ML in being lazy --- arguments to functions are only evaluated when and to the extent that they are needed --- and in being side-effect free. It has long been an article of faith in the functional programming community that languages like this are ideal candidates for program verification because of their `declarative' nature. This is clearly true for idealised languages, but real languages like Miranda bring their own complexities wh...