Results 1 -
8 of
8
Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine - Version 2.5
- JOURNAL OF FUNCTIONAL PROGRAMMING
, 1992
"... The Spineless Tagless G-machine is an abstract machine designed to support nonstrict higher-order functional languages. This presentation of the machine falls into three parts. Firstly, we give a general discussion of the design issues involved in implementing non-strict functional languages. Next, ..."
Abstract
-
Cited by 180 (19 self)
- Add to MetaCart
The Spineless Tagless G-machine is an abstract machine designed to support nonstrict higher-order functional languages. This presentation of the machine falls into three parts. Firstly, we give a general discussion of the design issues involved in implementing non-strict functional languages. Next, we present the STG language, an austere but recognisably-functional language, which as well as a denotational meaning has a well-defined operational semantics. The STG language is the "abstract machine code" for the Spineless Tagless G-machine. Lastly, we discuss the mapping of the STG language onto stock hardware. The success of an abstract machine model depends largely on how efficient this mapping can be made, though this topic is often relegated to a short section. Instead, we give a detailed discussion of the design issues and the choices we have made. Our principal target is the C language, treating the C compiler as a portable assembler. Version 2.5 of this paper (minus appendix) appe...
Parameter-Passing and the Lambda Calculus
, 1991
"... The choice of a parameter-passing technique is an important decision in the design of a high-level programming language. To clarify some of the semantic aspects of the decision, we develop, analyze, and compare modifications of the -calculus for the most common parameter-passing techniques, i.e., ca ..."
Abstract
-
Cited by 166 (20 self)
- Add to MetaCart
The choice of a parameter-passing technique is an important decision in the design of a high-level programming language. To clarify some of the semantic aspects of the decision, we develop, analyze, and compare modifications of the -calculus for the most common parameter-passing techniques, i.e., call-by-value and call-by-name combined with pass-by-worth and passby -reference, respectively. More specifically, for each parameter-passing technique we provide 1. a program rewriting semantics for a language with side-effects and first-class procedures based on the respective parameter-passing technique; 2. an equational theory that is derived from the rewriting semantics in a uniform manner; 3. a formal analysis of the correspondence between the calculus and the semantics; and 4. a strong normalization theorem for the imperative fragment of the theory (when applicable). A comparison of the various systems reveals that Algol's call-by-name indeed satisfies the well-known fi rule of the orig...
The Glasgow Haskell compiler: a technical overview
, 1992
"... We give an overview of the Glasgow Haskell compiler, focusing especially on way in which we have been able to exploit the rich theory of functional languages to give very practical improvements in the compiler. The compiler is portable, modular, generates good code, and is freely available. 1 Introd ..."
Abstract
-
Cited by 115 (18 self)
- Add to MetaCart
We give an overview of the Glasgow Haskell compiler, focusing especially on way in which we have been able to exploit the rich theory of functional languages to give very practical improvements in the compiler. The compiler is portable, modular, generates good code, and is freely available. 1 Introduction Computer Science is both a scientific and an engineering discipline. As a scientific discipline, it seeks to establish generic principles and theories that can be used to explain or underpin a variety of particular applications. As an engineering discipline, it constructs substantial artefacts of software and hardware, sees where they fail and where they work, and develops new theory to underpin areas that are inadequately supported. (Milner [1991] eloquently argues for this dual approach in Computer Science. ) Functional programming is a research area that offers an unusually close interplay between these two aspects (Peyton Jones [1992b]). Theory often has immediate practical appl...
Compiling Haskell by program transformation: a report from the trenches
- In Proc. European Symp. on Programming
, 1996
"... 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 proces ..."
Abstract
-
Cited by 52 (4 self)
- Add to MetaCart
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 ...
Let-Floating: Moving Bindings to Give Faster Programs
- PROCEEDINGS OF THE 1996 ACM SIGPLAN INTERNATIONAL CONFERENCE ON FUNCTIONAL PROGRAMMING
, 1997
"... Virtually every compiler performs transformations on the program it is compiling in an attempt to improve efficiency. Despite their importance, however, there have been few systematic attempts to categorise such transformations and measure their impact. In this paper we describe a particular group o ..."
Abstract
-
Cited by 47 (8 self)
- Add to MetaCart
Virtually every compiler performs transformations on the program it is compiling in an attempt to improve efficiency. Despite their importance, however, there have been few systematic attempts to categorise such transformations and measure their impact. In this paper we describe a particular group of transformations --- the "let-floating" transformations --- and give detailed measurements of their effect in an optimising compiler for the non-strict functional language Haskell. Let-floating has not received much explicit attention in the past, but our measurements show that it is an important group of transformations (at least for lazy languages), offering a reduction of more than 30% in heap allocation and 15% in execution time.
Optimal Type Lifting
- In Second Workshop on Types in Compilation
, 1998
"... . Modern compilers for ML-like polymorphic languages have used explicit run-time type passing to support advanced optimizations such as intensional type analysis, representation analysis and tagless garbage collection. Unfortunately, maintaining type information at run time can incur a large overhea ..."
Abstract
-
Cited by 13 (2 self)
- Add to MetaCart
. Modern compilers for ML-like polymorphic languages have used explicit run-time type passing to support advanced optimizations such as intensional type analysis, representation analysis and tagless garbage collection. Unfortunately, maintaining type information at run time can incur a large overhead to the time and space usage of a program. In this paper, we present an optimal type-lifting algorithm that lifts all type applications in a program to the top level. Our algorithm eliminates all run-time type constructions within any core-language functions. In fact, it guarantees that the number of types built at run time is strictly a static constant. We present our algorithm as a type-preserving source-to-source transformation and show how to extend it to handle the entire SML'97 with higher-order modules. 1 Introduction Modern compilers for ML-like polymorphic languages [16, 17] usually use variants of the Girard-Reynolds polymorphic -calculus [5, 26] as their intermediate language (I...
September 1999 CSPHD
- Department of Computer Science, University of Bristol
, 1999
"... This thesis presents the Brisk Machine #54#, a machine for executing functional languages, designed to be simple and #exible to support a number of run-time execution models for the Brisk compiler. Design considerations have been made to support dynamic loading, deterministic concurrency #23,51#, di ..."
Abstract
- Add to MetaCart
This thesis presents the Brisk Machine #54#, a machine for executing functional languages, designed to be simple and #exible to support a number of run-time execution models for the Brisk compiler. Design considerations have been made to support dynamic loading, deterministic concurrency #23,51#, distribution, debugging tools and logic programming #76#. To achieve this, the compiler's intermediate language, the Brisk Kernel Language BKL is simpler than the STG language #100#, as evaluation, extension and optimisation issues are relegated to special built-in functions. Moreover, function calls are saturated, as any function has an known arity and in every call to it, is applied to the rightnumber of arguments, which makes the machine dynamic and supports dynamic loading.
Problem: Expressions like
"... where go i = if i> n then [] else i: go (i + 1) sum [ ] = 0 sum (x: xs) = x + sum xs 2 Classical Shortcut Fusion [Gill et al. 1993] Example: upTo n = go 1 where go i = if i> n then [] else i: go (i + 1) sum [ ] = 0 sum (x: xs) = x + sum xs ..."
Abstract
- Add to MetaCart
where go i = if i> n then [] else i: go (i + 1) sum [ ] = 0 sum (x: xs) = x + sum xs 2 Classical Shortcut Fusion [Gill et al. 1993] Example: upTo n = go 1 where go i = if i> n then [] else i: go (i + 1) sum [ ] = 0 sum (x: xs) = x + sum xs

