A calculus for assignments in higher-order languages

Felleisen, Matthias; Friedman, Daniel P.

doi:10.1145/41625.41654

Cited by 52 publications

(43 citation statements)

References 8 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The implementation 1 and complete formal semantics 2 are publicly available. The interpreter is modeled after a CESK machine [3], extended with a value register named v for storing the value of the last expression that was evaluated. Execution of a program therefore proceeds through following a set of CESK state transitions.…”

Section: Discussionmentioning

confidence: 99%

“…Interpreters may implement these as they wish, allowing for maximal decoupling between the tracer and the interpreter. To give a concrete example however, when using a CESK machine as an interpreter [3], the program state would be the CESK state while a restartpoint may simply be the control component of this state. In this case, the restart function could then be implemented as a function that takes this control component and merges it with the rest of the CESK state, i.e., the environment, store and continuation stack.…”

Section: Tracing Interfacementioning

confidence: 99%

See 1 more Smart Citation

A formal foundation for trace-based JIT compilers

Vandercammen

Nicolay

Marr³

et al. 2015

Proceedings of the 13th International Workshop on Dynamic Analysis

View full text Add to dashboard Cite

Trace-based JIT compilers identify frequently executed program paths at run-time and subsequently record, compile and optimize their execution. In order to improve the performance of the generated machine instructions, JIT compilers heavily rely on dynamic analysis of the code. Existing work treats the components of a JIT compiler as a monolithic whole, tied to particular execution semantics. We propose a formal framework that facilitates the design and implementation of a tracing JIT compiler and its accompanying dynamic analyses by decoupling the tracing, optimization, and interpretation processes. This results in a framework that is more configurable and extensible than existing formal tracing models. We formalize the tracer and interpreter as two abstract state machines that communicate through a minimal, well-defined interface. Developing a tracing JIT compiler becomes possible for arbitrary interpreters that implement this interface. The abstract machines also provide the necessary hooks to plug in custom analyses and optimizations.

show abstract

Section: Discussionmentioning

confidence: 99%

Section: Tracing Interfacementioning

confidence: 99%

A formal foundation for trace-based JIT compilers

Vandercammen

Nicolay

Marr³

et al. 2015

Proceedings of the 13th International Workshop on Dynamic Analysis

View full text Add to dashboard Cite

show abstract

“…This machine is just the CESK machine of Felleisen & Friedman (1987). From here, we further exploit the store to allocate continuations, which corresponds to a well-known implementation technique used in functional language compilers (Shao & Appel, 1994).…”

Section: From Cek To the Abstract Ceskmentioning

confidence: 99%

Systematic abstraction of abstract machines

Horn¹,

Might²

2012

J. Funct. Prog.

View full text Add to dashboard Cite

We describe a derivational approach to abstract interpretation that yields novel and transparently sound static analyses when applied to well-established abstract machines for higherorder and imperative programming languages. To demonstrate the technique and support our claim, we transform the CEK machine of Felleisen and Friedman (Proc. of the 14th ACM SIGACT-SIGPLAN Symp. Prin. Program. Langs, 1987, pp. 314-325), a lazy variant of Krivine's machine (Higher-Order Symb. Comput. Vol 20, 2007, pp. 199-207), and the stackinspecting CM machine of Clements and Felleisen (ACM Trans. Program. Lang. Syst. Vol 26, 2004Vol 26, , pp. 1029Vol 26, -1052 into abstract interpretations of themselves. The resulting analyses bound temporal ordering of program events; predict return-flow and stack-inspection behavior; and approximate the flow and evaluation of by-need parameters. For all of these machines, we find that a series of well-known concrete machine refactorings, plus a technique of store-allocated continuations, leads to machines that abstract into static analyses simply by bounding their stores. These machines are parameterized by allocation functions that tune performance and precision and substantially expand the space of analyses that this framework can represent. We demonstrate that the technique scales up uniformly to allow static analysis of realistic language features, including tail calls, conditionals, mutation, exceptions, first-class continuations, and even garbage collection. In order to close the gap between formalism and implementation, we provide translations of the mathematics as running Haskell code for the initial development of our method.

show abstract

“…We start with an operational abstract machine that extends a control-store machine [16,17] with a remote procedure call mechanism. This abstract machine then generates structural and scoping constraints on event sequences, and so "bootstraps" the game semantics.…”

Section: Contract Expressivenessmentioning

confidence: 99%

“…This machine includes both code (C) and a store (S), and so in part functions much like Felleisen's C, S machine [16,17]. The [CALL] rule performs standard β-reduction within an evaluation context E. The rule [PRIM] leverages an auxiliary δ function to define the semantics of primitives.…”

Section: Semantics Of Modulesmentioning

confidence: 99%

Temporal higher-order contracts

2011

View full text Add to dashboard Cite

Behavioral contracts are embraced by software engineers because they document module interfaces, detect interface violations, and help identify faulty modules (packages, classes, functions, etc). This paper extends prior higher-order contract systems to also express and enforce temporal properties, which are common in software systems with imperative state, but which are mostly left implicit or are at best informally specified. The paper presents both a programmatic contract API as well as a temporal contract language, and reports on experience and performance results from implementing these contracts in Racket.Our development formalizes module behavior as a trace of events such as function calls and returns. Our contract system provides both non-interference (where contracts cannot influence correct executions) and also a notion of completeness (where contracts can enforce any decidable, prefix-closed predicate on event traces). Categories and Subject Descriptors Contract ExpressivenessLarge software systems typically consist of many modules (e.g., packages, classes, functions) produced by different development teams. When the system fails, an initial difficulty is fault localization: identifying the module that failed to perform as expected. Undocumented module interfaces are problematic for various reasons, not least because they lead to disagreements about which module is considered "at fault" and should be fixed.Software engineers embrace behavioral contracts because they address many of these problems. In particular, behavioral contracts provide a mechanism to explicitly document each module's assumptions and guarantees; to dynamically detect contract violations; and to identify faulty modules. Behavioral contracts are widely used in procedural, object-oriented, and functional languages, including Eiffel [36] Existing contract systems can express a range of interface specifications. Below, we consider a range of possible specifications for Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. 2. The argument function cmp in turn requires two arguments, both positive integers. This higher-order precondition constrains how the sort module can call the function argument cmp, and so is a guarantee provided by sort rather than an obligation on the client. Higherorder contract systems [19,15,22,24,45] support such preconditions by wrapping the cmp argument to enforce this property dynamically.3. The sort function is not re-entrant-it can only be called after all previous sort invocations have completed.Unlike the previous contracts that constrain how functions may be called, this temporal contract constrains when sort can be called [12,13]. This constra...

show abstract

A calculus for assignments in higher-order languages

Cited by 52 publications

References 8 publications

A formal foundation for trace-based JIT compilers

A formal foundation for trace-based JIT compilers

Systematic abstraction of abstract machines

Temporal higher-order contracts

Contact Info

Product

Resources

About