Concurrent Clean is an experimental, lazy, higher-order parallel functional programming language based on term graph rewriting. An important difference with other languages is that in Clean graphs are manipulated and not terms. This can be used by the programmer to control communication and sharing of computation. Cyclic structures can be defined. Concurrent Clean furthermore allows to control the (parallel) order of evaluation to make efficient evaluation possible. With help of sequential annotations the default lazy evaluation can be locally changed into eager evaluation. The language enables the definition of partially strict data structures which make a whole new class of algorithms feasible in a functional language. A powerful and fast strictness analyser is incorporated in the system. The quality of the code generated by the Clean compiler has been greatly improved such that it is one of the best code generators for a lazy functional language. Two very powerful parall...

Traditional first-class continuation mechanisms allow a captured continuation to be invoked multiple times. Many continuations, however, are invoked only once. This paper introduces one-shot continuations, shows how they interact with traditional multi-shot continuations, and describes a stack-based implementation of control that handles both one-shot and multi-shot continuations. The implementation eliminates the copying overhead for one-shot continuations that is inherent in multi-shot continuations. 1 Introduction Scheme [5] and some implementations of ML [17] provide continuations as first-class data objects. Continuations can be used to implement, at the source level, a number of interesting control features, such as loops, nonlocal exits, nonblind backtracking [22], nondeterministic computations [10, 14], and coroutines [7]. Source-level implementations of thread systems [9, 15, 21], especially in the area of graphical user interfaces (GUIs) [12, 13, 20, 23], are an important ...

This paper gives some examples of how computation in a number of languages may be described as graph rewriting, giving the Dactl notation for the examples shown. It goes on to present the Dactl model more formally before giving a formal definition of the syntax and semantics of the language. 2 Examples of Computation by Graph Rewriting

The G-machine (Johnsson, 1987; Peyton Jones, 1987) is a compiled graph reduction machine for lazy functional languages. The G-machine compiler contains many optimisations to improve performance. One set of such optimisations is designed to improve the performance of tail recursive functions. Unfortunately the abstract machine is subject to a space leak---objects are unnecessarily preserved by the garbage collector. This paper analyses why a particular form of space leak occurs in the G-machine, and presents some ideas for fixing this problem. This phenomena in other abstract machines is also examined briefly. 1. Compilers for conventional imperative languages How might a simple Pascal procedure, like the one shown below, be implemented ? procedure f; begin ... g; end; Typically the procedure which called f would set up a new stack frame for it, including such information as return addresses and any arguments passed to f. In turn, a naïve implementation of f might set up a further stack...

Distributed implementations of programming languages with implicit parallelism hold out the prospect that the parallel programs are immediately scalable. This paper presents some of the results of our part of Esprit 415, in which we considered the implementation of lazy functional programming languages on distributed architectures. A compiler and abstract machine were designed to achieve this goal. The abstract parallel machine was formally specified, using Miranda 1 . Each instruction of the abstract machine was then implemented as a macro in the Transputer Assembler. Although macro expansion of the code results in non-optimal code generation, use of the Miranda specification makes it possible to validate the compiler before the Transputer code is generated. The hardware currently available consists of five T800--25's, each board having 16M bytes of memory. Benchmark timings using this hardware are given. In spite of the straight forward code-generation, the resulting system compar...

Surprisingly, there is not a good fit between a syntax for linear logic in the style of Abramsky, and a semantics in the style of Seely. Notably, the Substitution Lemma is valid if and only if !A and !!A are isomorphic in a canonical way. An alternative syntax is proposed, that has striking parallels to Moggi's language for monads. In the old syntax, some terms look like the identity that should not, and vice versa; the new syntax eliminates this awkwardness. 1 Introduction This paper has two purposes: to show that linear logic has no substitute, and to propose one. The first part presents a standard syntax and semantics for linear logic, and notes some resulting difficulties. The linear logic is that of Girard [Gir87]. The syntax is based on lambda terms, following in the footsteps of Abramsky [Abr90]: the four rules associated with the `of course' type, Weakening, Contraction, Dereliction, and Promotion, are each represented by a separate term form. The semantics is based on categor...

The article introduces a novel notion of lazy rewriting. By annotating argument positions as lazy, redundant rewrite steps are avoided, and the termination behaviour of a term rewriting system can be improved. Some transformations of rewrite rules enable an implementation using the same primitives as an implementation of eager rewriting. 1

In this paper we will discuss how a good code generator can be built for (lazy) functional languages. Starting from Concurrent Clean, an experimental lazy functional programming language, code is generated for an intermediate abstract machine: the ABC machine. In this first pass many well-known optimisation techniques are included. However, we will also present some new ideas in this area, like the way in which strictness can be incorporated, and the implementation of higher order functions. In a second pass, the ABC code is translated to concrete target code for the Motorola MC680x0 processor. Again many optimisation methods appear to be applicable. Some of them (for example register allocation algorithms) are common for the implementation of other types of languages, but have to be adapted because of the specific properties of both source language and target machine. Other optimisations are specific for lazy functional languages, e.g. the implementation of higher order functions, eff...

Non-strict evaluation improves the expressive power of functional languages at the expense of an apparent loss of efficiency. In this paper we give examples of this expressive power, taking as an example an interactive functional program and describing the programming techniques depending on non-strict evaluation which improved its design. Implementation methods for non-strict languages have delivered poor performance precisely when such programming techniques have been used. This need not be the case, however, and in the second part of the paper we describe Tim, a method of implementing non-strict languages for which the penalty for using lazy evaluation is very small. 1 Introduction Effort in the functional programming community is today divided into two main activities: making efficient implementations of functional languages and exploiting the expressive power of these languages by writing elegant programs. To a large extent these activities are carried out by separate groups of p...

A criticism often levelled at functional languages is that they do not cope elegantly or efficiently with problems involving changes of state. In a recent paper [26], Wadler has proposed a new approach to these problems. His proposal involves the use of a type system based on the linear logic of Girard [7]. This allows the programmer to specify the "natural" imperative operations without at the same time sacrificing the crucial property of referential transparency. In this paper we investigate the practicality of Wadler's approach, describing the design and implementation of a variant of Lazy ML [2]. A small example program shows how imperative operations can be used in a referentially transparent way, and at the same time it highlights some of the problems with the approach. Our implementation is based on a variant of the G-machine [15, 1]. We give some benchmark figures to compare the performance of our machine with the original one. The results are disappointing: the cost of maintai...