Results 1  10
of
20
Views: A way for pattern matching to cohabit with data abstraction
, 1986
"... 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 ..."
Abstract

Cited by 174 (0 self)
 Add to MetaCart
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.
Elementary strong functional programming
, 1995
"... 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 o ..."
Abstract

Cited by 53 (0 self)
 Add to MetaCart
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.
A Logic for Miranda, Revisited
, 1994
"... . 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 e ..."
Abstract

Cited by 16 (6 self)
 Add to MetaCart
. 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 formallyverified 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...
On the implementation of construction functions for nonfree concrete data types
 in "16th European Symposium on Programming  ESOP’07
"... 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. Theori ..."
Abstract

Cited by 12 (0 self)
 Add to MetaCart
(Show Context)
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
An Operational Semantics for I/O in a Lazy Functional Language
 in Proc Functional Programming Languages and Computer Architecture
, 1993
"... 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 rea ..."
Abstract

Cited by 10 (3 self)
 Add to MetaCart
(Show Context)
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: synchronisedstream (primitive in Haskell), continuationpassing (derived in Haskell) and Landinstream 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...
Formulating Haskell
 In Workshop on Functional Programming, Ayr, 1992, Workshops in Computing
, 1993
"... 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 Introduc ..."
Abstract

Cited by 6 (1 self)
 Add to MetaCart
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...
Translating Haskell to Isabelle
, 2007
"... Abstract. We present partial translations of Haskell programs to Isabelle that have been implemented as part of the Heterogeneous Tool Set. The the target logic is Isabelle/HOLCF, and the translation is based on a shallow embedding approach. 1 ..."
Abstract

Cited by 4 (0 self)
 Add to MetaCart
Abstract. We present partial translations of Haskell programs to Isabelle that have been implemented as part of the Heterogeneous Tool Set. The the target logic is Isabelle/HOLCF, and the translation is based on a shallow embedding approach. 1
A Free Logical Foundation for Nonstrict Functions
"... 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 runtime errors. This is most natural in languages ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
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 runtime 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:
Relative Specification and Transformational Reuse of Functional Programs
 Lisp and Symbolic Computation
, 1990
"... 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 rearrang ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
(Show Context)
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 rearranges the specifying laws to obtain a collection of partial definitions for each unknown function, typically involving nondeterministic operators. The subsequent fusion stage combines each set of partial definitions into a single complete definition, thereby eliminating nondeterministic 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...