. 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...

. 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.

The Haskell Equational Reasoning Assistant (HERA) is an application written in Haskell that helps users construct and present equational reasoning style proofs[1]. In this paper we discuss the technology behind the user interface. 1 Introduction HERA is an equational reasoning assistant. It assists the user by taking requests for actions to be performed on partially complete proofs. Typical requests that the user might make include: ffl Use this specific lemma, on this specific sub-expression. ffl Perform case analysis on a formula, splitting it into a set of formulas. ffl Specify a new lemma to prove. ffl Request a reminder of the exact form of a lemma. HERA itself looks after the book-work, like what lemmas remain unproven, performing ff-conversions, etc. A first prototype of HERA was constructed with a straightforward ascii interface. This highlighted two significant problems: ffl The first and most important shortcoming of this interface was the problem of sub-expression sele...