QUickCheck is a tool which aids the Haskell programmer in formulating and testing properties of programs. Properties are described as Haskell functions, and can be automatically tested on random input, but it is also possible to define custom test data generators. We present a number of case studies, in which the tool was successfully used, and also point out some pitfalls to avoid. Random testing is especially suitable for functional programs because properties can be stated at a fine grain. When a function is built from separately tested components, then random testing suffices to obtain good coverage of the definition under test.

Despite the long list of publications on parser combinators, there does not yet exist a monadic parser combinator library that is applicable in real world situations. In particular naive implementations of parser combinators are likely to suffer from space leaks and are often unable to report precise error messages in case of parse errors. The Parsec parser combinator library described in this paper, utilizes a novel implementation technique for space and time efficient parser combinators that in case of a parse error, report both the position of the error as well as all grammar productions that would have been legal at that point in the input.

. Functional languages are particularly well-suited to the implementation of interpreters for domain-specific embedded languages (DSELs). We describe an implemented technique for producing optimizing compilers for DSELs, based on Kamin's idea of DSELs for program generation. The technique uses a data type of syntax for basic types, a set of smart constructors that perform rewriting over those types, some code motion transformations, and a back-end code generator. Domain-specific optimization results from chains of rewrites on basic types. New DSELs are defined directly in terms of the basic syntactic types, plus host language functions and tuples. This definition style makes compilers easy to write and, in fact, almost identical to the simplest embedded interpreters. We illustrate this technique with a language Pan for the computationally intensive domain of image synthesis and manipulation. 1 1 Introduction The "embedded" approach has proved an excellent technique for ...

Financial and insurance contracts do not sound like promising territory for functional programming and formal semantics, but in fact we have discovered that insights from programming languages bear directly on the complex subject of describing and valuing a large class of contracts. We introduce a combinator library that allows us to describe such contracts precisely, and a compositional denotational semantics that says what such contracts are worth. We sketch an implementation of our combinator library in Haskell. Interestingly, lazy evaluation plays a crucial role. 1 Introduction Consider the following nancial contract, C: the right to choose on 30 June 2000 between D1 Both of: D11 Receive $100 on 29 Jan 2001. D12 Pay $105 on 1 Feb 2002. D2 An option exercisable on 15 Dec 2000 to choose one of: D21 Both of: D211 Receive $100 on 29 Jan 2001. D212 Pay $106 on 1 Feb 2002. D22 Both of: D221 Receive $100 on 29 Jan 2001. D222 Pay $112 on 1 Feb 2003. The details of this contra...

www.dcs.gla.ac.uk/∼jtod/ Hydra is a computer hardware description language that integrates several kinds of software tool (simulation, netlist generation and timing analysis) within a single circuit specification. The design language is inherently concurrent, and it offers black box abstraction and general design patterns that simplify the design of circuits with regular structure. Hydra specifications are concise, allowing the complete design of a computer system as a digital circuit within a few pages. This paper discusses the motivations behind Hydra, and illustrates the system with a significant portion of the design of a basic RISC processor.

Abstract not found

valuation semantics. First, we will show how to translate an arbitrary contract, written in our language, into a value process, together with a handful of operations over these processes. These processes correspond directly to the mathematical and stochastic machinery used by nancial experts.

Abstract. We discuss the implications of the desire to augment a functionalprogramming language with a derivative-taking operator using forward-mode automatic differentiation (AD). The primary technical difficulty in doing so lies in ensuring correctness in the face of nested invocation of that operator, due to the need to distinguish perturbations introduced by distinct invocations. We exhibit a series of implementations of a referentially-transparent forward-mode AD derivative-taking operator, each of which uses a different non-referentially-transparent mechanism to distinguish perturbations. Even though the forward-mode AD derivative-taking operator is itself referentially transparent, we hypothesize that one cannot correctly formulate this operator as a function definition in current pure dialects of Haskell.

Motivated by some examples from functional programming, we propose a generalization of the notion of trace to symmetric premonoidal categories and of Conway operators to Freyd categories. We show that in a Freyd category, these notions are equivalent, generalizing a well-known theorem relating traces and Conway operators in cartesian categories.

ReFLect [4] is a functional programming language designed and implemented at Intel’s Strategic CAD Labs under the direction of Jim Grundy. The language is strongly typed and similar to ML, but provides certain reflection features intended for applications in industrial hardware design and verification. Like LISP, reFLect has quotation and antiquotation constructs that may be used to construct and decompose expressions in the language itself. Unlike LISP, these mechanisms are typed. The language also provides a primitive mechanism for pattern-matching, and in particular for defining functions over code by pattern-matching on the structure of reFLect expressions. The design of reFLect draws on the experience of applying an earlier reflective language called FL [1] to large-scale formal verification problems within Intel’s Forte framework [8]. One of the intended roles of reFLect is to be the host language for a functional HDL. As with other work based on Haskell [2, 7] or LISP [5, 6], a key requirement is the ability to simulate hardware models by program execution. Circuit descriptions are just functional programs, which we can simply run to simulate the circuits on test case inputs. But in addition to this simulation capability, we also wish to execute various operations on the abstract syntax of circuit descriptions written in the language. We want to be able to write programs that ‘see ’ the code of a circuit description.