Abstract. This paper develops a language for reasoning about concurrent functional I/O. We assume that the API is specified as statetransformers on a single world state. We then prove that under certain conditions evaluation in this language is deterministic, and give some examples. All properties were machine-verified using the Sparkle proofassistant and using Core-Clean as a meta-language. 1

The research presented in this thesis is about the design and implementation of Naira, a parallel, parallelising compiler for a rich, purely functional programming language. The source language of the compiler is a subset of Haskell 1.2. The front end of Naira is written entirely in the Haskell subset being compiled. Naira has been successfully parallelised and it is the largest successfully parallelised Haskell program having achieved good absolute speedups on a network of SUN workstations. Having the same basic structure as other production compilers of functional languages, Naira's parallelisation technology should carry forward to other functional language compilers. The back end of Naira is written in C and generates parallel code in the C language which is envisioned to be run on distributed-memory machines. The code generator is based on a novel compilation scheme specified using a restricted form of Milner's ß-calculus which achieves asynchronous communication. We present the f...

In imperative languages I/O is realized through sequences of sideeffecting function applications/ procedure invocations. This seems to be a suitable way of specifying I/O since it coincides with an intuitive understanding of it as sequences of actions. In contrast, functional languages carefully have to avoid side-effects to sustain referential transparency. Many different solutions, such as dialogues, continuations, monads and uniqueness typing have been proposed. The I/O facilities of Sac are based on uniqueness typing. Instead of using an explicit type attribute as in Clean, unique types are introduced as special modules called classes. To provide a syntax as close as possible to that of imperative languages, we propose two new mechanisms to be included on top of classes in Sac: a call-by-reference mechanism and global objects. Although a combination of both mechanisms allows for very imperative-like notations, we can define a purely functional semantics. Thus we combine the advant...

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

v Acknowledgements vi 1

syntax Term currently has the following abstract syntax: 119 data Term = TConst Int 120 | TRef FID 121 | TName Name 122 | TSelf 123 | TVar Name 124 | TFunc Name Term 125 | TApp Term Term 126 | TSeq Term Term 127 | TCall Term Term Term 128 | TAssign Term Term Term 129 | TOp (Int -> Int -> Int) Term Term 130 | TIf Term Term Term 131 | TOutput Term 132 | TFork Term 133 | TGo Place 134 | TClone Place 135 | TFrame Place [Assoc Name Term] 136 | TLet [Assoc Name Term] Term The meaning of these constructs is outlined in Table 2. A sketch of a possible concrete syntax is given in Table 3, Section 6.1.

ing away from the request and response lists. 10 Monadic style I/O operations can be implemented on top of synchronized streams in much the same way as CPS style I/O. A simple I/O monad (without error handling) is shown in Figure 5. In monadic style, the above example would look like this: main = doIO mainIO mainIO = readFileIO "forward" bindIO \ contents ® let revcontents = (unlines.reverse.lines) contents in writeFileIO "backward" revcontents) 2.3 Concurrency and GUI Programming We have seen above how you can use streams, continuations, or monads, to specify a sequence of I/O operations that the program should perform. For many purposes, a single sequence of I/O operations is an adequate description of the I/O behaviour of a program. But there are other cases. For programs that interact with several external entities (teletype terminals, other computers on a network, elements in a graphical user interface, robotic sensors/motors, etc.) there is usually no predetermined order in w...

The original aim of the work that led to this dissertation was to extend an existing, purely functional language with facilities for input/output and modular programming. The language is based on an untyped -calculus, i.e., program execution is defined as program transformation according to a fixed set of reduction rules including fi-reduction. Consistently, the implementation comprises an interactive reduction system which is integrated with a syntax-oriented editor: any sub-expression or program result can be submitted for (stepwise) reduction. There is no distinguished main program, no `global' environment and no explicit static part of the language -- in particular, there is no static type system. It is therefore not clear how to add one of the known solutions for input/output or modular programming to such a programming environment. Furthermore, simply adding features to the language would lead to a complex language design with weakly integrated parts, thus losing much of the appe...