Functional programming languages have banned assignment because of its undesirable properties. The reward of this rigorous decision is that functional programming languages are side-effect free. There is another side to the coin: because assignment plays a crucial role in Input/Output (I/O), functional languages have a hard time dealing with I/O. Functional programming languages have therefore often been stigmatised as inferior to imperative programming languages because they cannot deal with I/0 very well. In this paper we show that I/O can be incorporated in a functional programming language without loss of any of the generally accepted advantages of functional programming languages. This discussion is supported by an extensive account of the I/O system offered by the lazy, purely functional programming language Clean. Two aspects that are paramount in its I/O stem make the approach novel with respect to other approaches. These aspects are the technique of explicit multiple environment passing, and the Event I/O framework to program Graphical User I/O in a highly structured and high-level way. Clean file I/O is as powerful and flexible as it is in common imperative languages (one can read, write, and seek directly in a file). Clean Event I/O provides programmers with a high-level framework to specify complex Graphical User I/O. It has been used to write applications such as a window-based text editor, an object based drawing program, a relational database, and a spreadsheet program. These graphical interactive programs are completely machine independent, but still obey the look-and-feel of the concrete window environment being used. The specifications are completely functional and make extensive use of uniqueness typing, higher-order functions, and algebraic data type...

The interface with the outside world has always been one of the weakest points of functional languages. It is not easy to incorporate I/O without being allowed to do side-effects. Furthermore, functional languages allow redexes to be evaluated in any order while I/O generally has to be performed in a very specific order. In this paper we present a new solution for the I/O problem which we have incorporated in the language Concurrent Clean. Concurrent Clean offers a linear type system called Unique Types . It makes it possible to define functions with side-effects without violating the functional semantics. Now it is possible to change any object in the world in the way we wanted: e.g. arrays can be updated in-situ, arbitrary file manipulation is possible. We have used this powerful tool among others to create a library for window based I/O. Using an explicit environment passing scheme provides a high-level and elegant functional specification method for I/O, called Event...

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.

Existing functional languages appear not to be suitable for implementing systems which are inherently concurrent, such as operating system environments. Adaptations to functional languages developed to support such applications have in the past always involved the introduction of non-determinism.

In this paper we present a functional interleaved Event I/O system. This system is a generalization of the Event I/O system as incorporated into the lazy, purely functional programming language Clean. The Inter leaved Event I/O system offers features that are more commonly found outside the functional scene. These features are dynamic process creation, and two well-known forms of inter-process communication: asynchronous message passing, and data sharing. Both forms of communication are polymorphic and type-safe. As we are working in a functional language, messages can contain higher-order functions and arbitrarily complex algebraic types. Communication by data sharing is a restricted form of communication by global data structures. Nevertheless, the new system is still completely functional because the generalization is done within the pure functional framework. The Interleaved Event I/O system has been implemented and will become part of the new release of Clean. 1 Introduction R...

Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

This thesis describes an implementation of a small window-based graphical user interface toolkit for the X Window System written in the lazy functional language LML. By using this toolkit, a Haskell or LML programmer can create a user interface with menus, buttons and other graphical interface objects, without conforming to more or less imperative programming paradigms imposed if she were to use a traditional (imperative) toolkit. Instead, the power of the abstraction methods provided by Haskell or LML are used. The main abstraction we use is the fudget. Fudgets are combined in a hierarchical structure, and they interact by message passing. The current implementation is based on a sequential evaluator, but by using nondeterminism and oracles, we suggest how fudgets can evaluate in parallel. We believe that the toolkit can be extended to a full-feathered and practically useful high level graphical toolkit. ISBN 91-7032-841-2 i No one can have experienced to the fullest the true sense ...