Many compilers do some of their work by means of correctness-preserving, and hopefully performance-improving, program transformations. The Glasgow Haskell Compiler (GHC) takes this idea of "compilation by transformation" as its war-cry, trying to express as much as possible of the compilation process in the form of program transformations. This paper reports on our practical experience of the transformational approach to compilation, in the context of a substantial compiler. The paper appears in the Proceedings of the European Symposium on Programming, Linkoping, April 1996. 1 Introduction Using correctness-preserving transformations as a compiler optimisation is a well-established technique (Aho, Sethi & Ullman [1986]; Bacon, Graham & Sharp [1994]). In the functional programming area especially, the idea of compilation by transformation has received quite a bit of attention (Appel [1992]; Fradet & Metayer [1991]; Kelsey [1989]; Kelsey & Hudak [1989]; Kranz [1988]; Steele [1978]). A ...

Abstract not found

The context for this paper is functional computation by graph reduction. Our overall aim is more efficient use of memory. The specific topic is the detection of dormant cells in the live graph --- those retained in heap memory though not actually playing a useful role in computation. We describe a profiler that can identify heap consumption by such `useless' cells. Unlike heap profilers based on traversals of the live heap, this profiler works by examining cells postmortem. The new profiler has revealed a surprisingly large proportion of `useless' cells, even in some programs that previously seemed space-efficient such as the boot-strapping Haskell compiler nhc. 1 Introduction A typical computation by graph reduction involves a large and changing population of heap-memory cells. Taking a census of this population at regular intervals can be very instructive, both for functional programmers and for functional-language implementors. A heap profiler [RW93] records population counts for ...

The LOLITA natural language processor is an example of one of the ever-increasing number of large-scale systems written entirely in a functional programming language. The system consists of over 47,000 lines of Haskell code (excluding comments) and is able to perform a wide range of tasks such as semantic and pragmatic analysis of text, information extraction and query analysis. The efficiency of such a system is critical; interactive tasks (such as query analysis) must ensure that the user is not inconvenienced by long pauses, and batch mode tasks (such as information extraction) must ensure that an adequate throughput can be achieved. For the past three years the profiling tools supplied with GHC and HBC have been used to analyse and reason about the complexity of the LOLITA system. There have been good results, however experience has shown that in a large system the profiling life-cycle is often too long to make detailed analysis possible, and the results are often misleading. In response to these problems a profiler has been developed which allows the complete set of program costs to be recorded in so-called cost-centre stacks. These program costs are then analysed using a post-processing tool to allow the developer to explore the costs of the program in ways that are either not possible with existing tools or would require repeated compilations and executions of the program. The modifications to the Glasgow Haskell compiler based on detailed cost semantics and an efficient implementation scheme are discussed. The results of using this new profiling tool in the analysis of a number of Haskell programs are also presented. The overheads of the scheme are discussed and the benefits of this new system are considered. An outline is also given of how this approach can be modified to assist with the tracing and debugging of programs.

An Evaluation of LOLITA and related Natural Language Processing Systems Paul Callaghan Submitted to the University of Durham for the degree of Ph.D., August 1997 --------------------- This research addresses the question, "how do we evaluate systems like LOLITA?" LOLITA is the Natural Language Processing (NLP) system under development at the University of Durham. It is intended as a platform for building NL applications. We are therefore interested in questions of evaluation for such general NLP systems. The thesis has two parts.

Introduction Excessive requirements for memory space have in the past hindered or even prevented otherwise attractive applications of functional programming. Although this could be blamed in part on space-hungry implementation methods, in most cases it would have been possible to cut memory requirements very significantly by making a few changes to the source program. But there were no tools to help programmers make appropriate changes. Usage of heap memory was reported only as a total volume of allocations; there was no way to investigate how different parts of a program made demands on heap memory --- something which may be far from apparent in the source of a sizable program making use of lazy evaluation and higher-order functions. Finding the appropriate place to make a space-saving change could be very difficult. In the last few years, there has been a renewed effort to provide appropriate profiling tools for functional programmers. Because the first aspect of performance

In performance-critical parts of functional programs substantial performance improvements can be achieved by using unboxed, instead of boxed, data types. Unfortunately, polymorphic functions and data types cannot directly manipulate unboxed values, precisely because they do not conform to the standard boxed representation. Instead, specialised, monomorphic versions of these functions and data types, which manipulate the unboxed values, have to be created. This can be a very tiresome and error prone business, since specialising one function often requires the functions and data types it uses to be specialised as well. In this paper we show how to automate these tiresome consequential changes, leaving the programmer to concentrate on where to introduce unboxed data types in the first place. 1 Introduction Non-strict semantics certainly add to the expressive power of a language [8]. Sometimes the performance cost of this extra expressiveness is slight, but not always. It can happen that ...

I declare that this thesis is my own account of my research and contains as its main content work which has not previously been submitted for a degree at any tertiary education institution. Joel Kelso ii The purported advantages of Visual Programming, as applied to general purpose programming languages, have remained largely unfulfilled. The essence of this thesis is that functional programming languages have at least one natural visual representation, and that a useful programming environment can be based upon this representation. This thesis describes the implementation of a Visual Functional Programming Environment (VFPE). The programming environment has several significant features. • The environment includes a program editor that is inherently

Abstract not found

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