Machine We have described the type constructor language of CL and the typing rules for the main term-level constructs. In fact, the previous section contains all of the ACM Transactions on Programming Languages and Systems, Vol. TBD, No. TDB, Month Year. 20 D. Walker, K. Crary, and G. Morrisett #; #;# # h at r : # # # # f : Type #; ## # ; #{f :# f , x 1 :# 1 , . . . , xn :# n}; C # e # # f = #[# # ].(C, # 1 , . . . , #n ) # 0 at r f, x 1 , . . . , xn ## Dom(#) # #; #;# # fix f[# # ](C, x 1 :# 1 , . . . , xn :# n ).e at r : # f (h-fix) #; #;# # v i : # i (for 1 # i # n) # # r : Rgn #; #;# # #v 1 , . . . , vn # at r : ## 1 , . . . , #n # at r (h-tuple) #; #;# # h at r : # # # # # # = # : Type #; #;# # h at r : # (h-eq) #; #;# # v : # #; #;# # x : # (#(x) = #) (v-var) #; #;# # i : int (v-int) #; #;# # v : #[#:#, # # ].(C, # 1 , . . . , #n ) # 0 at r # # c : # #; #;# # v[c] : (#[# # ].(C, # 1 , . . . , #n ) # 0)[c/#] at r (v-type) #; #;# # v : #[# # C ## , # # ].(C # , # 1 , . . . , #n ) # 0 at r # # C # C ## #; #;# # v[C] : (#[# # ].(C # , # 1 , . . . , #n ) # 0)[C/#] at r (v-sub) #; #;# # v : # # # # # # = # : Type #; #;# # v : # (v-eq) Fig. 6. Capability static semantics: Heap and word values. information programmers or compilers require to write type-safe programs in CL. However, in order to prove a type soundness result in the style of Wright and Felleisen [Wright and Felleisen 1994], we must be able to type check programs at every step during their evaluation. In this section, we give the static semantics of the run-time values that are not normally manipulated by programmers, but are nevertheless necessary to prove our soundness result. At first, the formal definition ...

We present an efficient algorithm for computing the procedure call graph, the program representation underlying most interprocedural optimization techniques. The algorithm computes the possible bindings of procedure variables in languages where such variables only receive their values through parameter passing, such as Fortran. We extend the algorithm to accommodate a limited form of assignments to procedure variables. The resulting algorithm can also be used in analysis of functional programs that have been converted to Continuation Passing Style. We discuss the algorithm in relationship to other call graph analysis approaches. Many less efficient techniques produce essentially the same call graph. A few algorithms are more precise, but they may be prohibitively expensive depending on language features. Categories and Subject Descriptors: D.3.3 [Programming Languages]: Language constructs and features -- procedures, functions and subroutines, D.3.4 [Programming Languages]: Processors ...

The views and conclusions contained in this document arethose of the authors and should not be interpreted as representing o cial policies, either expressed or implied, of the Advanced We present a static and dynamic semantics for an abstract machine that evaluates expressions of a polymorphic programming language. Unlike traditional semantics, our abstract machine exposes many important issues of memory management, such as value sharing and control representation. We prove the soundness of the static semantics with respect to the dynamic semantics using traditional techniques. We then show how these same techniques may be used to establish the soundness of various memory management strategies, including type-based, tag-free garbage collection� tail-call elimination � and environment strengthening. Keywords: management Type theory and operational semantics are remarkably e ective tools for programming

Submitted for publication to Information and Computation. A summary of this paper appeared in TACS '97.

Programmers confront a minefield when they design interactive Web programs. Web interactions take place via Web browsers. With browsers, consumers can whimsically navigate among the various stages of a dialog and can thus confuse the most sophisticated corporate Web sites. In turn, Web services can fault in frustrating and inexplicable ways. The quickening transition from Web scripts to Web services lends these problems immediacy.

Plotkin, in his seminal article Call-by-name, call-by-value and the λ-calculus, formalized evaluation strategies and simulations using operational semantics and continuations. In particular, he showed how call-by-name evaluation could be simulated under call-by-value evaluation and vice versa. Since Algol 60, however, call-by-name is both implemented and simulated with thunks rather than with continuations. We recast

Abstract. Scheme and Smalltalk continuations may have unlimited extent. This means that a purely stack-based implementation of continuations, as suffices for most languages, is inadequate. We review several implementation strategies for continuations and compare their performance using instruction counts for the normal case and continuation-intensive synthetic benchmarks for other scenarios, including coroutines and multitasking. All of the strategies constrain a compiler in some way, resulting in indirect costs that are hard to measure directly. We use related measurements on a set of benchmarks to calculate upper bounds for these indirect costs.

. Providing type structure for extremely low-level programming languages, such as assembly language, yields a number of important benefits for compiler and systems projects, where reliability and security are crucial concerns. We discuss some of the issues involved in designing type systems for low-level languages, and identify some general principles that simplify constructing a proof of soundness. 1 Introduction Over the past twenty years, there has been tremendous progress in the design and foundations of type systems for high-level programming languages culminating in the design of such languages as Modula-3, Standard ML, Haskell, and Java. The goal of much of the research was to strengthen the logic of a type system so that a richer class of abstractions and invariants could be stated and yet enforced automatically. Recently, we (and others) have been exploring the design, applications, and foundations of type systems for extremely low-level languages. In particular, we have conc...

Lazy allocation is a model for allocating objects on the execution stack of a high-level language which does not create dangling references. Our model provides safe transportation into the heap for objects that may survive the deallocation of the surrounding stack frame. Space for objects that do not survive the deallocation of the surrounding stack frame is reclaimed without additional effort when the stack is popped. Lazy allocation thus performs a first-level garbage collection, and if the language supports garbage collection of the heap, then our model can reduce the amortized cost of allocation in such a heap by filtering out the short-lived objects that can be more efficiently managed in LIFO order. A run-time mechanism called result expectation further filters out unneeded results from functions called only for their effects. In a shared-memory multi-processor environment, this filtering reduces contention for the allocation and management of global memory. Our model performs s...

A substantial amount of work has been devoted to the proof of correctness of various program analyses but much less attention has been paid to the correctness of compiler optimisations based on these analyses. In this paper we tackle the problem in the context of strictness analysis for lazy functional languages. We show that compiler optimisations based on strictness analysis can be expressed formally in the functional framework using continuations. This formal presentation has two benefits: it allows us to give a rigorous correctness proof of the optimised compiler; and it exposes the various optimisations made possible by a strictness analysis. 1 Introduction Realistic compilers for imperative or functional languages include a number of optimisations based on non-trivial global analyses. Proving the correctness of such optimising compilers can be done in three steps: 1. proving the correctness of the original (unoptimised) compiler; Correspondence regarding this paper should be ...