Johnsson, Thomas. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology (1987).  Home/Search   Document Not in Database   Summary   Related Articles   Check

....their abstract machine recompute non linear values, so they should preserve the strong single pointer property. However, their abstract machines are formulated slightly too abstractly to capture memory management properties. Wakeling and Runciman [WR91] briefly mention a variant of the G machine [Aug87, Joh87] which they use to implement a linear language based on the work of Wadler [Wad90, Wad91] They do not prove any memorymanagement properties, but their abstract machine would have been ideal for this purpose, since it represents the linear and non linear storage graphs explicitly. Even though ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University of Technology, 1987.

....it refers to f . g dominates f in the call graph. If the source program is parameter lifted, then a block oated program degenerates to recursive equations. 2.2. 2 Lambda lifting algorithm We consider Johnsson s algorithm, which rst performs parameter lifting and then performs block oating [4, 23, 24]. Figure 5 describes the parameter lifting part of Johnsson s algorithm. To parameter lift a program, all free variables of a function must be explicitly passed as parameters to this function. Thus, all callers of the function must be provided with these variables as additional arguments. The ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology,

....work. Section 8 concludes. Throughout the article, we assume variable hygiene, i.e. that no name clashes can occur. Also, the term block is assumed to mean a collection of declarations, possibly functions, followed by a main expression. 2 Lambda Lifting We consider Johnsson s algorithm [3, 19, 20]. Johnsson s target is the Gmachine, which can run recursive equations efficiently. Lambda lifting transforms a block structured program into a set of recursive equations. These recursive equations correspond to local functions in the block structured program. Each equation is passed variables ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

....refers to f . g dominates f in the call graph. If the source program is parameter lifted, then a block floated program degenerates to recursive equations. 2.2. 2 Lambda lifting algorithm We consider Johnsson s algorithm, which first performs parameter lifting and then performs block floating [4,23,24]. Figure 5 describes the parameter lifting part of Johnsson s algorithm. To parameter lift a program, all free variables of a function must be explicitly passed as parameters to this function. Thus, all callers of the function must be provided with these variables as additional arguments. The ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

....User defined functions are compiled into instruction sequences for G machine. The instructions construct and manipulate explicitly graphs for expressions to reduce the expressions to their values. G machine compilation rules and state transition rules are shown in Figure 3 and Figure 4[7][9]. The graph for a function application, which is a thunk, has two representations: the ap representation and the vap representation. These are described in Figure 1. The ap representation always has two entries: one for function part and the other for argument part. The vap representation has the ....

....are replaced with the right pointer of their corresponding ap node. Rules 3,5,6 in Figure 4) ffl If the thunk is in the vap representation, it is not necessary to follow some pointers and to check the number of arguments if the exact number of arguments are known. This is a strategy in HBC[9]. The pointers in the vap representation are stored on the stack(Rule 4 in Figure 4) Note that the stack keeps a pointer to the root of the current redex for updating operation. Lazy evaluation requires sharing the value of an expression, instead of reevaluating the expression whenever its value ....

[Article contains additional citation context not shown here]

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University, 1987.

....then in principle fold unfold transformations are valid. 16 4 Conclusion The claim has been made that Deforestation would be a suitable candidate for inclusion in an advanced compiler for a functional language, after the fashion of the many program transformations employed in the LML compiler ([Aug87, Joh87]) In order for this to be convincing, we must be assured of termination; that is what, by means of a reformulation, we have established here. Our reformulation may have other benefits: anyone who has tried to transform terms by hand using the old formulation using case expressions will realise ....

T. Johnsson, Compiling lazy functional languages. Ph.D. dissertation, Department of Computer Science, Chalmers Tekniska Hogskola, Goteborg, Sweden, 1987.

....include the runtime structures that are essential for running computations both forward and backward. The machine considered here is a modi ed version of Landin s secd machine [Lan64] which has been variously used as a basic model for more sophisticated functional or function based machinery [CMQ83,Joh87]. The four stack like runtime structures it supports are known to be a control structure C which, as a sequence of terms or instructions, holds the program text to be executed; a workspace stack S which (temporarily) holds evaluated terms and eventually the result of the computation; an ....

....count value accordingly. 7 Outline of a reversible graph reducer The semcd machine may be used as a starting point for the design of more realistic reversible graph reduction machinery. These machines usually have n ary functions transformed into supercombinators or some equivalent closed forms [CMQ83,Joh87,GK96] and then compiled to (abstract) machine code. Supercombinator applications create, e.g. on some runtime stack, frames of some n argument (pointer) entries, push return addresses, and then branch out into the supercombinator codes. This action is roughly equivalent to creating on stack E of the ....

Johnsson, T.: Compiling Lazy Functional Languages, PhD Thesis, Chalmers University of Technology, Goeteborg, 1987

....the program. This offered the advantage of having a fixed set of rules which can be implemented directly in hardware and gave rise to the notion of instructions of an abstract machine. The next sections describe the most important abstract machines. 3.2. 3 The G machine The first abstract machine [59], 6] based on supercombinator reduction is the G machine. Supercombinators are translated into a sequence of machine instructions, which form the abstract machine code or g code, for efficiency. The abstract machine instructions, when executed, construct an instance of the supercombinator body. ....

....can also be represented in the extended notation as: f = f (g,h) f (g,h) x y = g . h . indicating that f is represented as a node referencing g and h and that selfcontained code is generated for f . 8. 4 The Brisk Abstract Machine Many approaches to compiling functional languages [59], 6] 136] 15] 105] use abstract machines with imperative machine instructions to provide the operational semantics of programs; see also [14] 99] With the STG Machine [100] a different approach was taken. The STG language is a small, low level, intermediate language which is on the one ....

Thomas Johnsson. Compiling lazy functional languages. PhD thesis, Chalmers University, 1987.

.... The transformation of tail recursive functions into loops is a standard technique performed in all optimizing Lisp and Scheme compilers e.g. Kra88] There is also a considerable amount of literature on all aspects of the compilation of (in particular lazy) functional languages, e.g. PJ87] Joh87] Aug87] FH88] and [PL92] The iterated compositions of D are essentially a combination of the higher order operator fold with (a generalized form of) the notion of list comprehensions. List comprehensions were introduced in KHC and its successor Miranda [Tur85] to construct lists without ....

Thomas Johnsson. Compiling Lazy Functional Languages, Part I. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

....We also discuss some optimisations made to facilitate efficient code generation on real hardware and give some measurements of the efficiency of the machine. 1 Introduction Much current research on graph reduction for applicative programming is centred round the ideas of Hughes [3] and Johnsson [4]. These are based on the principle of making all function definitions into super combinators by source level transformations; the most important of these transformations is lambda lifting. This paper presents a different point of view. We feel that there is still much mileage to be made from a ....

....simultaneously if several processes could run in parallel on suitable hardware) may use this same closure without any copying. Each separate invocation of the function however will bind its own argument by placing it in the argument register A. With this method, the operation of lambda lifting [3,4] is replaced by an operation carried out at run time but without extra penalty. The lambda lifting method involves transforming functions to others which are combinators i.e. those having no free variables. This is achieved by adding extra arguments (by source transformations) through which ....

[Article contains additional citation context not shown here]

T.Johnsson, Compiling Lazy Functional Languages, Ph.D. thesis, Chalmers University of Technology, 1987

....matching compiler . Lambda lifting . A pass to create a number of GCLA functions one for each supercombinator produced by the lambda lifting pass. The lexical analyzer and parser were written by Gran Falkman and the rest of the translator by the author of this paper. The methods used are from [7,8,14,18,19] and are not described here since they are standard material in compilers for functional languages. We will simply make some remarks on how they help us achieve our purposes. 3.3.1 Removing syntactic sugar Some constructs in TML like if expressions, boolean operators and pattern matching in ....

....to enhance the efficiency of pattern matching. In Sect. 4 we show how these are evaluated by a special inference rule in GCLA. 3.3.3 Lambda Lifting In GCLA all function definitions are at the same level, that is there are no local functions or lambda abstractions. By lambda lifting the programs [14,18,19] we get a program where all function definitions (the supercombinators) are at the same outermost level which is exactly what we want. 3.3.4 Creating a GCLA Definition When we have performed the above transformations we get a list of supercombinator definitions and an expression to be evaluated. ....

T. Johnsson, Compiling lazy functional languages, Ph.D thesis, Chalmers University of technology, Sweden, 1987.

....This can reduce the paging costs of a program substantially, and can also improve its cache performance. We do not evaluate this opportunity here. 2.2 The STG machine The STG machine [19, 16, 17] is a model for the compilation of lazy functional languages. It is derived from the G machine [2, 14] and the Spineless G machine [5] In the STG machine every program object is represented as a closure. The rst eld of each closure is a pointer to statically allocated entry code, above which sits an info table that contains static information relating to the object s type, notably its layout. ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University, Sweden, 1987.

....This can reduce the paging costs of a program substantially, and can also improve its cache performance. We do not evaluate this opportunity here. 2.2 The STG machine The STG machine [18, 15, 16] is a model for the compilation of lazy functional languages. It is derived from the G machine [2, 13] and the Spineless G machine [4] In the STG machine every program object is represented as a closure. The rst eld of each closure is a pointer to statically allocated entry code, above which sits an info table that contains static information relating to the object s type, notably its layout. ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University, Sweden, 1987.

....The result is the application node push s (push s I z o I y ) which is scanned by unwind s . r A naive implementation of call by need is possible without introducing marks. The graph construction and reduction are distinct operations. This makes it possible to systematically update the graph [9]. For example, the reduction of an application node would store its address. The definition of mkApp s would be of the form mkApp s = l s x 1 .l s x 2 .push s (push s o push s x 2 o x 1 ) The address would be updated after the construction of the reduced graph, that is mkFun s = l s f.push s ....

....suited to parallel execution because it has no global environment structure. So, in our framework, the transformations modeling the compilation of b reduction for graph reducers should not use the e component. We present two transformations to model the environment management used in the G machine[9] and in the SKI machine[14] We first introduce general transformations which can be used along with any previous compilation of control. Then, we specialize them to model accurately model existing graph reduction implementations. Finally, we briefly compare them. 4.1 A G machine like abstraction ....

[Article contains additional citation context not shown here]

T. Johnsson. Compiling Lazy Functional Languages. PhD Thesis, Chalmers University, 1987.

....P.J. Landin [18] il y a plus de trente ans, une plthore de nouvelles machines abstraites ou techniques de compilation a t propose. La liste des machines abstraites fonctionnelles comprend (entre autres) la SECD [18] la Fam [6] la Cam [7] la CMCM [20] la Tim [11] la Zam [19] la G machine [15] et la machine de Krivine [8] D autres implantations ne sont pas dcrites par une machine abstraite mais par des collections de transformations ou de techniques de compilation. Citons par exemple, les compilateurs bass sur la conversion CPS [1] 13] 17] De plus, de nombreux papiers proposent ....

T. Johnsson. Compiling Lazy Functional Languages. PhD Thesis, Chalmers University, 1987.

....is their implementation. Since Landin s seminal proposal, 30 years ago [31] a plethora of new abstract machines or compilation techniques have been proposed. The list of existing abstract machines includes the SECD [31] the Cam [10] the CMCM [36] the Tim [20] the Zam [32] the G machine [27] and the Krivine machine [11] Other implementations are not described via an abstract machine but as a collection of transformations or compilation techniques such as compilers based on continuation passing style (CPS) 2] 22] 30] 52] Furthermore, numerous papers present optimizations often ....

....s e 2 o mkApp s ) o mkApp s Ks = l s e.l s x.push s e Is = l s x. push s x In the same way, the transformation Ag dsb (a dupl less, swap less and mkbind less abstraction algorithm) can be specialized for graph code ( 18] It would then precisely model the classical abstraction of the G machine ([27]) 5 COMPILATION OF CONTROL TRANSFERS A conventional machine executes linear sequences of basic instructions. In our framework, reducing expressions of the form appclos o E involves evaluating a closure and then returning to E. We have to make calls and returns explicit. We present here two ....

[Article contains additional citation context not shown here]

T. Johnsson. Compiling Lazy Functional Languages. PhD Thesis, Chalmers University, 1987.

....proposal of Landin, 30 years ago [19] a plethora of new abstract machines or compilation techniques have been proposed. The list of existing abstract machines includes (but is surely not limited to) the SECD [19] the FAM [6] the CAM [7] the CMCM [21] the TIM [11] the ZAM [20] the G machine [16] and the Krivine machine [8] Other implementations are not described via an abstract machine but as a collection of transformations or compilation techniques such as CPS based compilers [1] 13] 18] Furthermore, numerous papers present optimizations often adapted to a specific abstract machine or ....

T. Johnsson. Compiling Lazy Functional Languages. PhD Thesis, Chalmers University, 1987.

....results are detailed in Section 4. Section 5 concludes the paper and outlines further work. 2 The STG machine The Shared Term Graph machine (formerly the Spineless Tagless G machine) 17, 18, 19] is a model for the compilation of lazy functional languages. It is derived from the G machine [2, 12] and the Spineless G machine [4] The principal distinguishing feature of the STG machine lies in its representation of program objects. Program objects take several forms: they have di erent (program level) types, they have di erent layouts of pointers and immediate values, they may be evaluated ....

T. Johnsson, Compiling Lazy Functional Languages, Ph.D thesis, Chalmers University, Sweden, 1987.

....visible state) from communication (i.e. stream generation) results in a simpler but no less expressive programming model. 5 Conclusions In its support for non strict evaluation of record objects COE s operational semantics most closely resembles various dataflow and graph reduction languages [21, 25, 28]. The coercion operators in COE distinguish it from these languages in obvious ways however; in terms of COE s support for direct manipulation of naming environments, it bears a strong resemblance to Symmetric Lisp [15, 16, 14] a nonstrict language that provides support for first class naming ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

.... used for coercion placement, the flow information is exploited by update avoidance and cheap eagerness optimizations (the latter is an instance of speculative evaluation; if an expression is cheap to evaluate and guaranteed not to yield a run time error, there is no need to build a thunk for it [16, 12, 20]) Since several optimizations are program wide, separate compilation is not supported. The compiler is described more fully in the author s PhD thesis [4] The compiler does not support floating point numbers; the only representations are box and int. 4.1 Unboxed Objects in Data Structures ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University of Technology, 1987.

....4 Implementation The method is applicable in all implementations of lazy functional languages that use graph reduction and can handle indirection nodes. In this section we present some optimizations that can be performed, if the language implementation uses a stack machine, like the G machine [Joh87]. updatePat is a function internal to the compiler, so the user can not use it explicitly. It is only used in pattern bindings, and the stack context is completely determined when it is applied. With that knowledge, we can improve the efficiency of the transformation above. Instead of letting ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, February 1987.

....not take a position regarding the representation of terms in our kernel language. The compiler may choose different data structures, such as, parse trees or graphs, for terms in different modules. The idea of viewing intermediate forms as languages is not new in the functional language community [6, 9, 14], but it is still rare in the Fortran community (Pingali s work being a notable exception [15] In this paper we will show certain aspects of the process of compiling Id, an implicit parallel language [13] Id is a higher order functional language augmented with I structures [5] and M structures ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University of Technology, Department of Computer Science, 1987.

....Tail Recursion Without Space Leaks Richard Jones Computing Laboratory University of Kent at Canterbury Canterbury, Kent, CT2 7NF rej ukc.ac. uk Abstract 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 ....

....still constructed, and its spine unwound. Such problems are addressed by compiled versions of graph reduction, which are discussed next. 3. The G machine shortcircuits this mechanism The G machine is a very fast implementation of graph reduction based on compiling supercombinators (Hughes, 1984; Johnsson, 1987), that includes a large number of compile time optimisations to improve performance. For tail calls in particular, rather than constructing the graph of functions applied to arguments, calling functions rearrange the Stack, replacing their own arguments with the arguments of the called function. ....

Johnsson, T. 1987 Compiling Lazy Functional Languages, PhD thesis, Chalmers University of Technology.

....of these languages allowed implementation to move from interpretation towards compilation, with substantial gain in performance. Cardelli s abstract machine FAM [3] developed for the compilation of strict functional languages was an important step in this search for efficiency. Johnsson [10] developed a strategy for compiling lazy functional languages, described as an abstract stack machine, called the G Machine. The basic principle of the G Machine is to avoid generating graphs. The code generated by the G Machine when executed produces time and space performance at least an order ....

....the G Machine is to avoid generating graphs. The code generated by the G Machine when executed produces time and space performance at least an order of magnitude faster than interpreted functional languages. The original G Machine implemented at Chalmers, Gotheburg, by Johnsson and his collegues [10], generated code in VAX780 Assembly language, which made implementation extremely hard and machine dependant. It was common sense in the community of implementation of functional languages that assembly language implementation was the price to pay if one wanted efficiency. The Chalmers LML ....

T.Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, January 1987.

....the fact that the datum a is an instance of the data term t. Following this semantics, programming in the language is regarded as defining functions. Computation is evaluating an expression by applying defined functions. With certain simple syntactical transformation techniques, such as lifting [Joh87], all the local definitions can be removed. Thus, a functional program may generally have the form e where P : 8 : f 1 s 1 = e 1 . fn s n = e n where e is the ground expression to be evaluated and P is the set of global function definitions. Computationally, P is taken as a ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Progr. Methodology Group, Chalmers University of Gothenborg, 1987.

....than one instruction fetch hence we must have wide instructions. But we must also be able to write the constructed object in a single operation hence we need wide data words as well. 2 Basic machinery The BWM is designed to execute the calculus. In many ways it resembles the G machine [Joh87] and TIM [FW87] but in some ways it is even simpler. The basic machine can only run the pure calculus by tree reduction. We will in this section assume that all applications will have few enough arguments to fit into a single big word. All these restrictions will be lifted in later sections. ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, February 1987.

....for ML considered as a rewriting system [Maranget, 1992] The implemented strategy is correct in the sense that it terminates and produces a result whenever any other strategy does. When designing a semantics or at least a precise definition for lazy functional languages such as LML or Haskell [Johnsson, 1987, Hudak et al. 1992] the denotation of pattern matching expressions should, in my view, be based upon a matching predicate very similar to the Laville s definition (definition 2.3) This definition of matching is appealing because of its simplicity and generality. The compilers described in this ....

....the compilers presented here detect all non sequential RR n2385 34 Luc Maranget matchings and can thus react appropriately when given such a matching as input. An appropriate reaction is usually to issue a warning message before producing a non correct automaton. Published language definitions [Johnsson, 1987, Hudak et al. 1992] present a different semantics for pattern matching: they select one particular sequential semantics (i.e. left to right) This approach lacks the generality and elegance of Laville s solution. First, there is no natural correspondence between this left to right matching ....

T. Johnsson, "Compiling Lazy Functional Languages". Ph.D. thesis, Chalmers University of Technology, Sweden, 1987.

....memory management time into account. 2 A brief tour of GAML The language implemented by GAML is the ML language with lazy semantics, very close to lazy ML of INRIA Rocquencourt, BP 105, 78153 LE CHESNAY CEDEX, FRANCE. This work was partially funded by DRET under grant N o 8780814. Goteborg [3, 8]. The syntax is actually closer to the one of CAML [14] Unlike LML, GAML implements lazy pattern matching as defined by [9, 12] LML relies on a more classical left to right evaluation order of the discriminating expression [3] Lazy pattern matching, adapts the evaluation order to each set of ....

....Lazy pattern matching, adapts the evaluation order to each set of patterns, guaranteeing termination whenever possible. GAML also has a simple module system which allows type safe separate compilation. Compiling lazy ML language to the G machine has been extensively described in the literature [3, 8, 11]. However, we shall examine this notions first, in order to make our extensions easier to understand. 2.1 Simplified GAML We consider the language defined by the following grammar: programs : p : let rec f n1 1 [ x 1 : x n1 = e 1 and : and f nm m [ x 1 : x nm ....

[Article contains additional citation context not shown here]

Thomas Johnsson, Compiling Lazy Functional Languages, Ph. D. Thesis, Chalmers University of Technology, 1987.

....1.1: Structure of the Naira compiler The pattern matching compiler takes the AST input, compiles the syntactic sugar inside patterns and produces an AST closer to the underlying computation model. The lambda lifter then inputs the resulting AST and turns functions into supercombinators [Hugh82, John87, PeLe91] Lambda lifting is particularly beneficial in a parallel implementation since supercombinator invocations can be distributed across the processors of the parallel machine without worrying about access to free variables. The AST is then type checked and further simplified to produce an ....

....above, is one way of coping with this problem. One other solution is to adopt a variable naming convention which avoids the problem [Bare84] or to use a calculus which does not contain variables at all [Turn79b] Another approach is to use a program transformation technique, called lambda lifting [John87, FiHa88, Peyt87, PeLe91] so that the free variables of each local function definition are passed as extra parameters to the function. The approach which abstracts away variables is based on a result in mathematical logic which says that variables as they are used in logic and ordinary mathematics ....

[Article contains additional citation context not shown here]

T Johnsson, Compiling Lazy Functional Languages. Ph.D. Thesis, Department of Computer Science, Chalmers University of Technology, G oteborg, Sweden, 1987.

.... the efficient implementation of lazy functional languages we developed Categorical Multi Combinators [7] This system was the result of the evolution of several other rewriting systems [5, 6] which have similar aims, and are based on the original system of Categorical Combinators [1] In Johnsson [2] an abstract machine for compiling lazy functional languages is presented. This machine puts together the best features of Turner s and Landin s machines with new code optimisation techniques. Johnsson s G machine was a major achievement in the efficient implementation of lazy functional ....

....laws with a very low pattern matching complexity and avoids the generation of trivially reducible sub expressions. In Categorical Multi Combinators function application is denoted by juxtaposition. We take juxtaposition to be left associative. We assume that programs have already been lifted [2] to remove non local references from the bodies of functions. The compilation algorithm [7] for translating each function in the script into Categorical Multi Combinators is: T .1) fun x i : x j z n j a] fun 7 L n Gamma1 (R x i ; x j n Gamma1; 0 a) T .2) a : b] ....

[Article contains additional citation context not shown here]

T.Johnsson, Compiling Lazy Functional Languages, Ph.D. Thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, January 1987.

....there is no need to update it and it can be stored on the top of the control stack. The original G machine always writes out a graph in heap but SGM avoids doing it when a graph is not shared. Hence, it reduces the heap usage. Johnsson uses vector application nodes (VAP nodes) in his implementation[Joh87], which also reduces the allocation of the heap significantly. A VAP node is a merged representation of the spine of application nodes (AP nodes) It is used when the arity of the function on the tip of the spine can be known at compile time. A VAP node can be thought as a specialized version of ....

....4, we describe the modified G machine which performs the tag forwarding. In section 5, we show the experimental results and discuss the performance affecting factors briefly. The summary and concluding remarks are given in section 6. 2 G machine In this section, we briefly review the G machine[Joh84, Joh87, Pey87, PL91]. G machine consists of two parts: the compilation part and the transition part. The compilation part consists of a set of compilation schemes that defines the transformation from supercombinators to sequences of G machine instructions. Informally, a supercombinator is a function such that any ....

[Article contains additional citation context not shown here]

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, January 1987.

....complexity and avoids the generation of trivially reducible sub expressions. Independently, there has been much interest in compiled versions of functional languages which run much more quickly on von Neumann machines than do interpreters. Johnsson, with his implementation of Lazy ML [3], showed that it is possible to get fast implementations of lazy functional languages. Johnsson s implementation model was described as the G Machine [13, 3] The basic principle of the G Machine is to avoid generating graph nodes when it is unnecessary. Several optimisations to the G Machine ....

....of functional languages which run much more quickly on von Neumann machines than do interpreters. Johnsson, with his implementation of Lazy ML [3] showed that it is possible to get fast implementations of lazy functional languages. Johnsson s implementation model was described as the G Machine [13, 3]. The basic principle of the G Machine is to avoid generating graph nodes when it is unnecessary. Several optimisations to the G Machine are suggested in [13, 3] In [16] there is an analysis of these optimisations and their performance figures obtained with several different benchmark programs. ....

[Article contains additional citation context not shown here]

T.Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, January 1987.

....a local definition for each argument for which the TIM code generator would push a label. So the partial application of C given above is replaced by let x = sqrt 64 in C 1 x 3 In our implementation, local definitions are implemented using a technique reminiscent of that used by the G machine [7]. For each local definition we: ffl allocate an extra argument (called a hole ) in the current frame; ffl generate code for the right hand side, treating all references to the locally bound name as references to the corresponding hole; ffl push a label to the code for the right hand side into ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University of Technology, S-412 96 Goteborg, February 1987.

....computational cost of a program before and after a transformation. The model allows the computational cost to be determined for several actual models of computation, such as functional languages and imperative languages. Chapter 3 Lambda Lifting 3. 1 Introduction We consider Johnsson s algorithm [4, 26, 27]. Johnsson s target is the G machine, which can run recursive equations efficiently. Lambda lifting transforms a block structured program into a set of recursive equations. These recursive equations correspond to local functions in the block structured program. Each equation is passed variables ....

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

....compiler, ffl lambda lifting, ffl a pass to create a number of GCLA functions one for each supercombinator produced by the lambda lifting pass. The lexical analyzer and parser were written by Goran Falkman and the rest of the translator by the author of this paper. The methods used are from [3, 4, 12, 16, 17] and are not described here since they are standard material in compilers for lazy functional languages. We will simply make some remarks on how they help us achieve our purposes. 3.3 First Order Programs We first show how first order programs can be translated and then in Section 3.4 describe ....

....the removal of syntactic sugar and applies some program transformations to ensure that pattern matching is done efficiently. 3.3.3 Lambda Lifting In GCLA all function definitions are at the same level, that is, there are no local functions or lambda abstractions. By lambda lifting the programs [12, 16, 17] we get a program where all function definitions (the supercombinators) are at the same outermost level which is exactly what we want. We use what is called Johnsson style lambda lifting in [17] 3.3.4 Creating a GCLA Definition When we have performed the above transformations we get a list of ....

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, February 1987.

....simultaneously if several processes could run in parallel on suitable hardware) may use this same closure without any copying. Each separate invocation of the function however will bind its own argument by placing it in the argument register MA. With this method, the operation of lambda lifting [Hugh84,John85,John87] is replaced by an operation carried out at run time but without extra penalty. The lambda lifting method involves transforming functions to others which are combinators i.e. those having no free variables. This is achieved by adding extra arguments (by source transformations) through which ....

Johnsson, T., Compiling Lazy Functional Languages, PhD Thesis, Chalmers University of Technology, 1987

....Section 4 discusses the overheads of this modification. Section 5 concludes the paper and outlines further work. 2 The Spineless Tagless G machine The Spineless Tagless G machine[11] 12] 13] is a model for the compilation of lazy functional languages. It is derived from the G machine[2][10] and the Spineless G machine[5] hence the name) The STG machine has been developed and implemented by Simon Peyton Jones and the GRASP team at Glasgow University. The principal distinguishing feature of the STG machine lies in its representation of program objects. Program objects take several ....

T. Johnsson, Compiling Lazy Functional Languages, Ph.D thesis, Chalmers University, Sweden, 1987.

....as verifying and transforming programs automatically. These merits of functional programs are more evident in writing programs for parallel processing [1] For the efficient execution of functional programs, several compiling techniques based on dataflow and reduction models, have been proposed [2, 3] and implemented on commercially available parallel machines or simulators [4, 5, 6] such as the h; Gi machine by Thomas Johnsson [4] the Process Oriented Dataflow System by Lubomir Bic [6] and the SISAL system [7] The h; Gi machine is an implementation of a graph reduction machine, which is ....

Thomas Johnsson, Compiling Lazy Functional Language, Chalmers University of Technology DEPARTMENT OF COMPUTER SCIENCES (1987).

No context found.

Johnsson, Thomas. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology (1987).

No context found.

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

No context found.

T. Johnsson, Compiling lazy functional languages, Ph.D. thesis, Department of Computing Science, Chalmers University of Technology (1987).

No context found.

T. Johnsson. Compiling Lazy Functional Languages, Part I. PhD thesis, Department of Computer Science, Chalmers University, Sweden, 1987.

No context found.

T. Johnsson. Compiling Lazy Functional Languages. PhD thesis, Department of Computer Science, Chalmers University of Technology, Goteborg, Sweden, 1987.

No context found.

Thomas Johnsson. Compiling Lazy Functional Languages. PhD thesis, Chalmers University of Technology, 1987.

No context found.

T.Johnsson, `Compiling Lazy Functional Languages', Ph.D. Thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, January 1987. IMPLEMENTINGSASLUSINGCATEGORICALMULTI-COMBINATORS29

No context found.

Thomas Johnsson. Compiling Lazy Functional Languages, Part I. PhD thesis, Department of Computer Sciences, Chalmers University of Technology, Goteborg, Sweden, 1987.

No context found.

T Johnsson, Compiling Lazy Functional Languages. Ph.D. Thesis, Department of Computer Science, Chalmers University of Technology, Gothenborg, Sweden, 1987.

No context found.

Thomas Johnsson [1987], "Compiling lazy functional languages," PhD thesis, PMG, Chalmers University, Goteborg, Sweden.

No context found.

T. Johnsson, Compiling Lazy Functional Languages, Ph.D. Thesis, Department of Computer Science, Chalmers University of Technology, Gothenborg, Sweden, 1987.

No context found.

T. Johnsson. Compiling Lazy Functional Languages. Doctoral thesis, Chalmers Tekniska Hogskola, Goteborg, Sweden, 1987.

First 50 documents  Next 50

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC