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.

This paper presents a technique for preserving the power of general program transformations in the presence of a rich collection of distinguishable error values. This is accomplished by introducing an annotation, "Safe", to mark occurrences of functions that cannot produce errors. Succinct and general algebraic laws can be expressed using Safe, thereby giving program transformations in a language with many error values the same power and generality as program transformations in a language with only a single error value (such as FP [Bac78]). In fact, the Safe mechanism accomplishes much more. It actually strengthens equational reasoning by providing a sufficient condition on a program context E(\Delta) and functions f and g; such that E(f) j E(g) even if f 6j g:

FL is the result of an e ort to design a practical functional programming language based on Backus' FP. This paper provides an introduction to and critique of the FL language. The language e ort is analyzed from several points of view: language design, implementation, and user experiences. Emphasis is placed on the unusual aspects of FL, its strengths and weaknesses, and how FL compares with other functional programming languages. 1

Constructs for expressing exception handling can greatly help to avoid clutter in code by allowing the programmer to separate the code to handle unusual situations from the code for the normal case. Handling exceptions in functional languages has received less attention mainly due to the inherent conflict between the control flow oriented approach of exception handlers and the functional style of evaluation. This has (i) resulted in loss of referential transparency, (ii) made non-strict constructs behave as strict functions, and most importantly, (iii) forced an order of evaluation on the subexpressions in a function. In this paper, we propose a new approach to embed exception handlers in functional languages. The proposed approach discards the conventional view of treating exceptions as a means of effecting a control transfer; instead, exceptions are used to change the state of an object. The two types of exceptions, Terminate and Resume, are treated differently in this paper. A Termi...