Results 1 -
5 of
5
Extensible Denotational Language Specifications
- SYMPOSIUM ON THEORETICAL ASPECTS OF COMPUTER SOFTWARE, NUMBER 789 IN LNCS
, 1994
"... Traditional denotational semantics assigns radically different meanings to one and the same phrase depending on the rest of the programming language. If the language is purely functional, the denotation of a numeral is a function from environments to integers. But, in a functional language with impe ..."
Abstract
-
Cited by 30 (4 self)
- Add to MetaCart
Traditional denotational semantics assigns radically different meanings to one and the same phrase depending on the rest of the programming language. If the language is purely functional, the denotation of a numeral is a function from environments to integers. But, in a functional language with imperative control operators, a numeral denotes a function from environments and continuations to integers. This paper introduces a new format for denotational language specifications, extended direct semantics, that accommodates orthogonal extensions of a language without changing the denotations of existing phrases. An extended direct semantics always maps a numeral to the same denotation: the injection of the corresponding number into the domain of values. In general, the denotation of a phrase in a functional language is always a projection of the denotation of the same phrase in the semantics of an extended language---no matter what the extension is. Based on extended direct semantics, i...
The Formal Relationship Between Direct and Continuation-Passing Style Optimizing Compilers: A Synthesis of Two Paradigms
, 1994
"... Compilers for higher-order programming languages like Scheme, ML, and Lisp can be broadly characterized as either "direct compilers" or "continuation-passing style (CPS) compilers", depending on their main intermediate representation. Our central result is a precise correspondence between the two co ..."
Abstract
-
Cited by 13 (0 self)
- Add to MetaCart
Compilers for higher-order programming languages like Scheme, ML, and Lisp can be broadly characterized as either "direct compilers" or "continuation-passing style (CPS) compilers", depending on their main intermediate representation. Our central result is a precise correspondence between the two compilation strategies. Starting from
Towards Machine-checked Compiler Correctness for Higher-order Pure Functional Languages
- CSL '94, European Association for Computer Science Logic, Springer LNCS
, 1994
"... . In this paper we show that the critical part of a correctness proof for implementations of higher--order functional languages is amenable to machine--assisted proof. An extended version of the lambdacalculus is considered, and the congruence between its direct and continuation semantics is proved. ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
. In this paper we show that the critical part of a correctness proof for implementations of higher--order functional languages is amenable to machine--assisted proof. An extended version of the lambdacalculus is considered, and the congruence between its direct and continuation semantics is proved. The proof has been constructed with the help of a generic theorem prover --- Isabelle. The major part of the problem lies in establishing the existence of predicates which describe the congruence. This has been solved using Milne's inclusive predicate strategy [5]. The most important intermediate results and the main theorem as derived by Isabelle are quoted in the paper. Keywords: Compiler Correctness, Theorem Prover, Congruence Proof, Denotational Semantics, Lambda Calculus 1 Introduction Much of the work done previously in compiler correctness concerns restricted subsets of imperative languages. Some studies involve machine--checked correctness---e.g. Cohn [1], [2]. A lot of research h...
Towards Leakage Containment
, 1992
"... Functional programs are organized into procedures, each encapsulating a specific task. A procedure should not cause its callers to repeat its work. This forced repetition of work we call leakage. In this paper we describe several common instances of leakage, and show how they can be eliminated usin ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
Functional programs are organized into procedures, each encapsulating a specific task. A procedure should not cause its callers to repeat its work. This forced repetition of work we call leakage. In this paper we describe several common instances of leakage, and show how they can be eliminated using an extension of continuation-passing style. 1 Introduction A goal of programming is to divide a complex task into simpler parts. In a well organized program each of these simpler tasks is represented by a procedure. Each procedure should perform a distinct action. Its user should not have to be conscious about the details of its implementation and should not have to undo or repeat work performed by it. This excess interaction between procedures is called leakage. When leakage is eliminated, the clarity and correctness of programs is enhanced. Our goal in this paper is to show how some leakage can be removed by using a generalization of continuation-passing style. We emphasize the developm...

