Results 1 - 10
of
37
A Natural Semantics for Lazy Evaluation
, 1993
"... We define an operational semantics for lazy evaluation which provides an accurate model for sharing. The only computational structure we introduce is a set of bindings which corresponds closely to a heap. The semantics is set at a considerably higher level of abstraction than operational semantics f ..."
Abstract
-
Cited by 169 (3 self)
- Add to MetaCart
We define an operational semantics for lazy evaluation which provides an accurate model for sharing. The only computational structure we introduce is a set of bindings which corresponds closely to a heap. The semantics is set at a considerably higher level of abstraction than operational semantics for particular abstract machines, so is more suitable for a variety of proofs. Furthermore, because a heap is explicitly modelled, the semantics provides a suitable framework for studies about space behaviour of terms under lazy evaluation.
Deriving a Lazy Abstract Machine
- Journal of Functional Programming
, 1997
"... Machine Peter Sestoft Department of Mathematics and Physics Royal Veterinary and Agricultural University Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark E-mail: sestoft@dina.kvl.dk Version 6 of March 13, 1996 Abstract We derive a simple abstract machine for lazy evaluation of the lambda cal ..."
Abstract
-
Cited by 57 (2 self)
- Add to MetaCart
Machine Peter Sestoft Department of Mathematics and Physics Royal Veterinary and Agricultural University Thorvaldsensvej 40, DK-1871 Frederiksberg C, Denmark E-mail: sestoft@dina.kvl.dk Version 6 of March 13, 1996 Abstract We derive a simple abstract machine for lazy evaluation of the lambda calculus, starting from Launchbury's natural semantics. Lazy evaluation here means non-strict evaluation with sharing of argument evaluation, that is, call-by-need. The machine we derive is a lazy version of Krivine's abstract machine, which was originally designed for call-by-name evaluation. We extend it with datatype constructors and base values, so the final machine implements all dynamic aspects of a lazy functional language. 1 Introduction The development of an efficient abstract machine for lazy evaluation usually starts from either a graph reduction machine or an environment machine. Graph reduction machines perform substitution by rewriting the term graph, that is, the program itself...
Lazy Narrowing in a Graph Machine
, 1990
"... The paper investigates the implementation of lazy narrowing in the framework of a graph reduction machine. By extending an appropriate architecture for purely functional languages an abstract graph narrowing machine for a functional logic language is constructed. The machine is capable of perform ..."
Abstract
-
Cited by 36 (4 self)
- Add to MetaCart
The paper investigates the implementation of lazy narrowing in the framework of a graph reduction machine. By extending an appropriate architecture for purely functional languages an abstract graph narrowing machine for a functional logic language is constructed. The machine is capable of performing unification and backtracking.
A Functional Correspondence between Call-by-Need Evaluators and Lazy Abstract Machines
, 2004
"... ..."
Tail Recursion Without Space Leaks
- Journal of Functional Programming
, 1991
"... 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. Unfortu ..."
Abstract
-
Cited by 29 (0 self)
- Add to MetaCart
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...
Formally Based Profiling for Higher-Order Functional Languages
, 1997
"... Costs Cost of Denoted Application A Case expression C Evaluating a thunk V Updating a thunk U Allocating a heap object H Entering an scc E vocabulary: ---cost center (cc): a label to which costs are attributed. ---cost attribution (`): a finite mapping of cost centers to costs. A cost attribution re ..."
Abstract
-
Cited by 29 (0 self)
- Add to MetaCart
Costs Cost of Denoted Application A Case expression C Evaluating a thunk V Updating a thunk U Allocating a heap object H Entering an scc E vocabulary: ---cost center (cc): a label to which costs are attributed. ---cost attribution (`): a finite mapping of cost centers to costs. A cost attribution records the total costs attributed to each cost center. Two cost attributions are combined using (an overloaded) + . We also use \Gamma to remove costs from an attribution. (` 1 + attr ` 2 )(cc) = ` 1 (cc) + cost ` 2 (cc) (` 1 \Gamma attr ` 2 )(cc) = ` 1 (cc) \Gamma cost ` 2 (cc) ---heap (\Gamma; \Delta; \Theta;\Omega\Gamma1 an annotated mapping from variable names to expressions. We use the notation \Gamma[x cc 7! e] to extend the heap \Gamma with a mapping from x to the expression e annotated with cost center cc. In general, the cost center attached to a heap binding is the cost center which enclosed that binding. It serves two purposes: to ensure correct cost attribution when a thunk (un...
Functional Back-Ends within the Lambda-Sigma Calculus
, 1996
"... We define a weak -calculus, oe w , as a subsystem of the full -calculus with explicit substitutions oe * . We claim that oe w could be the archetypal output language of functional compilers, just as the -calculus is their universal input language. Furthermore, oe * could be the adequate theory to e ..."
Abstract
-
Cited by 20 (0 self)
- Add to MetaCart
We define a weak -calculus, oe w , as a subsystem of the full -calculus with explicit substitutions oe * . We claim that oe w could be the archetypal output language of functional compilers, just as the -calculus is their universal input language. Furthermore, oe * could be the adequate theory to establish the correctness of simplified functional compilers. Here, we illustrate these claims by proving the correctness of four simplified compilers and runtime systems modeled as abstract machines. The four machines we prove are the Krivine machine, the SECD, the FAM and the CAM. Thereby, we give the first formal proofs of Cardelli's FAM and of its compiler.
Non-Strict Languages - Programming and Implementation
, 1994
"... 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-str ..."
Abstract
-
Cited by 19 (0 self)
- Add to MetaCart
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...
Abstract machines for programming language implementation
- FUTURE GENERATION COMPUTER SYSTEMS
, 2000
"... We present an extensive, annotated bibliography of the abstract machines designed for each of the main programming paradigms (imperative, object oriented, functional, logic and concurrent). We conclude that whilst a large number of efficient abstract machines have been designed for particular langua ..."
Abstract
-
Cited by 16 (0 self)
- Add to MetaCart
We present an extensive, annotated bibliography of the abstract machines designed for each of the main programming paradigms (imperative, object oriented, functional, logic and concurrent). We conclude that whilst a large number of efficient abstract machines have been designed for particular language implementations, relatively little work has been done to design abstract machines in a systematic fashion.
Compilation of Functional Languages Using Flow Graph Analysis
, 1994
"... syntax, and syntactic and semantic domains of a flow graph Figure 9. Semantic equations Def and Exp of a flow graph The first argument to the functions Def and Exp specifies a set of nodes that represent a flow graph, from which the element(s) of current interest are selected by pattern matching. ..."
Abstract
-
Cited by 16 (12 self)
- Add to MetaCart
syntax, and syntactic and semantic domains of a flow graph Figure 9. Semantic equations Def and Exp of a flow graph The first argument to the functions Def and Exp specifies a set of nodes that represent a flow graph, from which the element(s) of current interest are selected by pattern matching.

