In this paper we present a type system for graph rewrite systems: uniqueness typing . It employs usage information to deduce whether an object is `unique' at a certain moment, i.e. is only locally accessible. In a type of a function it can be specified that the function requires a unique argument object. The correctness of type assignment guarantees that no external access on the original object will take place in the future. The presented type system is proven to be correct. We illustrate the power of the system by defining an elegant quicksort algorithm that performs the sorting in situ on the data structure. 1. Introduction Some operations on complex data structures (such as arrays) cannot be implemented efficiently without allowing a form of destructive updating. For convenience, we speak about those functions as `destructively using' their arguments. In case of graph-like implementations of functional languages without any precautions, this destructive usage is dangerous: on the ...

This paper describes the history of Haskell, including its genesis and principles, technical contributions, implementations and tools, and applications and impact. 1.

. We describe a process extension to a lazy functional programming system, intended for applications with graphical user interfaces (GUIs). In the extended language, dynamically-created processes communicate by asynchronous message passing. We illustrate the use of the language, including as an extended example a simple board game in which squares are implemented as concurrent processes. We also describe a window manager, itself implemented in the extended functional language. Keywords: functional language, processes, concurrency, window manager, Gofer. 1 Introduction and Motivation Most of the time, elements of a graphical user interface (GUI) operate independently. For example, a menu doesn't interact with the rest of the program until the user selects an option. The user can highlight options, open up further menus or move the menu around the screen, all without doing anything that should concern any other element of the program. Popular languages such as C do not readily lend the...

. The functional programming language Clean has a high level I/O system (version 0.8) in which complex yet efficient interactive programs can be created. In this paper we present its successor (version 1.0), the object I/O system. We consider some of the design considerations that have influenced the design of the new I/O system greatly. Key issues are compositionality, orthogonality, and extensibility. Apart from design, the object I/O system improves on its predecessor by two major contributions: programmers can introduce polymorphic local state at every (collection of) user interface component(s) and programmers can create interactive processes in a flexible way. All interface components can communicate with each other by sharing state but also using powerful message passing primitives in both synchronous, asynchronous, and uni- or bi-directional way. Using the message passing mechanism remote procedure calling can be added easily. The result is an object oriented I/O...

. Graphical user interfaces (GUIs) are hard to combine with functional programming. Using a suitable combination of monads, we are able to tame the imperative aspects of graphical I/O in a straightforward and elegant way. We present a concept to integrate lightweight GUIs into the functional framework, together with a library of basic functions and layout combinators to manipulate the GUI. An implementation of this library, using a set of high-level graphical I/O routines, is outlined. Examples demonstrate the simple way in which applications can be written. 1 Introduction Everybody wants to use graphical user interfaces. And everybody wants to use functional programming languages. Unfortunately, these concepts are hard to combine: I/O, and graphical I/O in particular, is imperative in nature, and thus contradictory to the functional paradigm. Our goal is to reconcile these two concepts, by developing a framework in which a functional programmer smoothly can provide his program with a...

At first sight, I/O in a pure functional language is not as straightforward as in imperative languages. For some years work has been going on to alleviate these problems, and there are now a number of different approaches. The purpose of this report is twofold --- firstly we shall review the problems encountered in performing I/O in a functional language and look at some of the ways these might be conquered, and secondly we shall look at some more recent solutions to I/O which encompass graphical interfaces.

Arrays are probably the most widely used data structure in imperative programming languages, yet functional languages typically only support arrays in a limited manner, or prohibit them entirely. This is not too surprising, since most other mutable data structures, such as trees, have elegant immutable analogues in the functional world, whereas arrays do not. Previous attempts at addressing the problem have suffered from one of three weaknesses, either that they don't support arrays as a persistent data structure (unlike the functional analogues of other imperative data structures), or that the range of operations is too restrictive to support some common array algorithms efficiently, or that they have performance problems. Our technique provides arrays as a true functional analogue of imperative arrays with the properties that functional programmers have come to expect from their data structures. To efficiently support array algorithms from the imperative world, we provide O(1) operations for single-threaded array use. Fully persistent array use can also be provided at O(1) amortized cost, provided that the algorithm satisfies a simple requirement as to uniformity of access. For those algorithms which do not access the array uniformly or single-threadedly, array reads or updates take at most O(log n) amortized time, where n is the size of the array. Experimental results indicate that the overheads of our technique are acceptable in practice for many applications.

. We present the design rationale of a constructor class-based implementation of a graphical user interface library. This library, named TkGofer, provides a convenient way to write window-oriented applications in the pure, functional programming language Gofer, using the user interface toolkit Tcl/Tk. The principal contribution of the approach embodied in the library is its flexibility and its type security to specify the appearance and behaviour of individual widgets and their composition. 1 Introduction Functional programming languages offer many advantages to programmers. Using functional languages often results in faster development times and shorter code compared with imperative languages. Furthermore, reasoning about and reusing programs is easier. Recent research in the field of functional programming resulted in new concepts such as monads to tame the imperative aspects of IO and state [12], and constructor classes to deal with higher order polymorphism [7]. Today, the specific...

We present a new approach to the old problem of adding global mutable state to purely functional languages. Our idea is to extend the language with “witnesses, ” which is based on an arguably more pragmatic motivation than past approaches. We give a semantic condition for correctness and prove it is sufficient. We also give a somewhat surprising static checking algorithm that makes use of a network flow property equivalent to the semantic condition via reduction to a satisfaction problem for a system of linear inequalities.

User interfaces are normally based on low-level trickery either within the run-time system, or in a separate program which has been connected to the stream I/O system of the language. We present a new twist to this by giving some intelligence to the outside system, which will have greater control of the interface. This has a number of benefits: it makescreating new programs easier, increasesthe efficiency of the resulting system, and improves the separation between the two halves of the system. 1 Introduction Many people have written of the problems functional languages have with user interfaces, and have proposed various solutions. These solutions range from the simplistic [9], to the powerful [10], with some truly innovative possibilities explored [4,5]. These systems usually have, at some level, the functional program communicating with an external system, receiving events from the user or system, and replying with requests, telling the system what to do next. This can be done eith...