Results 11  20
of
464
The semantics of Scheme controlflow analysis
 School of Computer Science, Pittsburgh
, 1991
"... This is a followon to my 1988 PLDI paper, “ControlFlow Analysis in Scheme”[9]. I usethe methodof abstractsemantic interpretations to explicate the controlflow analysis technique presented in that paper. I begin with a denotational semantics for CPS Scheme. I then present an alternate semantics th ..."
Abstract

Cited by 57 (3 self)
 Add to MetaCart
(Show Context)
This is a followon to my 1988 PLDI paper, “ControlFlow Analysis in Scheme”[9]. I usethe methodof abstractsemantic interpretations to explicate the controlflow analysis technique presented in that paper. I begin with a denotational semantics for CPS Scheme. I then present an alternate semantics that precisely expresses the controlflow analysis problem. I abstract this semantics in a natural way, arriving at two different semantic interpretations giving approximate solutions to the flow analysis problem, each computable at compile time. The development of the final abstract semantics provides a clear, formal description of the analysis technique presented in “ControlFlow Analysis in Scheme.” 1
Extracting a Data Flow Analyser in Constructive Logic
 Proc. of the 13th European Symposium on Programming, volume 2986 of LNCS
, 2004
"... Abstract. We show how to formalise a constraintbased data flow analysis in the specification language of the Coq proof assistant. This involves defining a dependent type of lattices together with a library of lattice functors for modular construction of complex abstract domains. Constraints are exp ..."
Abstract

Cited by 56 (19 self)
 Add to MetaCart
Abstract. We show how to formalise a constraintbased data flow analysis in the specification language of the Coq proof assistant. This involves defining a dependent type of lattices together with a library of lattice functors for modular construction of complex abstract domains. Constraints are expressed in an intermediate representation that allows for both efficient constraint resolution and correctness proof of the analysis with respect to an operational semantics. The proof of existence of a correct, minimal solution to the constraints is constructive which means that the extraction mechanism of Coq provides a provably correct data flow analyser in ocaml. The library of lattices together with the intermediate representation of constraints are defined in an analysisindependent fashion that provides a basis for a generic framework for proving and extracting static analysers in Coq. 1
The pitfalls of verifying floatingpoint computations
 ACM Transactions on programming languages and systems
"... Current critical systems often use a lot of floatingpoint computations, and thus the testing or static analysis of programs containing floatingpoint operators has become a priority. However, correctly defining the semantics of common implementations of floatingpoint is tricky, because semantics ma ..."
Abstract

Cited by 56 (3 self)
 Add to MetaCart
(Show Context)
Current critical systems often use a lot of floatingpoint computations, and thus the testing or static analysis of programs containing floatingpoint operators has become a priority. However, correctly defining the semantics of common implementations of floatingpoint is tricky, because semantics may change according to many factors beyond sourcecode level, such as choices made by compilers. We here give concrete examples of problems that can appear and solutions for implementing in analysis software. 1
A modular, polyvariant, and typebased closure analysis
 In ICFP ’97 [ICFP97
"... We observe that the principal typing property of a type system is the enabling technology for modularity and separate compilation [10]. We use this technology to formulate a modular and polyvariant closure analysis, based on the rank 2 intersection types annotated with controlflow information. Modu ..."
Abstract

Cited by 56 (1 self)
 Add to MetaCart
(Show Context)
We observe that the principal typing property of a type system is the enabling technology for modularity and separate compilation [10]. We use this technology to formulate a modular and polyvariant closure analysis, based on the rank 2 intersection types annotated with controlflow information. Modularity manifests itself in a syntaxdirected, annotatedtype inference algorithm that can analyse program fragments containing free variables: a principal typing property is used to formalise it. Polyvariance manifests itself in the separation of different behaviours of the same function at its different uses: this is formalised via the rank 2 intersection types. As the rank 2 intersection type discipline types at least all (core) ML programs, our analysis can be used in the separate compilation of such programs. 1
A Type System for LockFree Processes
, 2002
"... Interpretation. An alternative way to analyze the behavior of a concurrent program would be to use abstract interpretation [4, 5]. Actually, from a very general viewpoint, our typebased analysis of locks can be seen as a kind of abstract interpretation. We can read a type judgment # P as "# ..."
Abstract

Cited by 55 (8 self)
 Add to MetaCart
Interpretation. An alternative way to analyze the behavior of a concurrent program would be to use abstract interpretation [4, 5]. Actually, from a very general viewpoint, our typebased analysis of locks can be seen as a kind of abstract interpretation. We can read a type judgment # P as "# is an abstraction of a concrete process P ." (The relation "#" corresponds to a pair of abstraction /concretization functions.) Indeed, we can regard a type environment as an abstract process: we have defined reductions of type environments in Section 3.7.
Trust in the λCalculus
 JOURNAL OF FUNCTIONAL PROGRAMMING
, 1995
"... This paper introduces trust analysis for higherorder languages. Trust analysis encourages the programmer to make explicit the trustworthiness of data, and in return it can guarantee that no mistakes with respect to trust will be made at runtime. We present a confluent λcalculus with explicit tru ..."
Abstract

Cited by 55 (0 self)
 Add to MetaCart
(Show Context)
This paper introduces trust analysis for higherorder languages. Trust analysis encourages the programmer to make explicit the trustworthiness of data, and in return it can guarantee that no mistakes with respect to trust will be made at runtime. We present a confluent λcalculus with explicit trust operations, and we equip it with a trusttype system which has the subject reduction property. Trust information in presented as two annotations of each function type constructor, and type inference is computable in O(n³) time.
19831993: The Wonder Years of Sequential Prolog Implementation
, 1993
"... This report surveys the major developments in sequential Prolog implementation during the period 19831993. In this decade, implementation technology has matured to such a degree that Prolog has left the university and become useful in industry. The survey is divided into four parts. The first part ..."
Abstract

Cited by 52 (4 self)
 Add to MetaCart
(Show Context)
This report surveys the major developments in sequential Prolog implementation during the period 19831993. In this decade, implementation technology has matured to such a degree that Prolog has left the university and become useful in industry. The survey is divided into four parts. The first part gives an overview of the important technical developments starting with the Warren Abstract Machine (WAM). The second part presents the history and the contributions of the major software and hardware systems. The third part charts the evolution of Prolog performance since Warren's DEC10 compiler. The fourth part extrapolates current trends regarding the evolution of sequential logic languages, their implementation, and their role in the marketplace.
Analyses, Optimizations and Extensions of Constraint Handling Rules
, 2005
"... This is a summary of the Ph.D. thesis of Tom Schrijvers [4]. Constraint Handling Rules (CHR) [3] is a rulebased language commonly embedded in a host language. It combines elements of Constraint Logic Programming and term rewriting. Several implementations of CHR exist: in Prolog, Haskell, Java and ..."
Abstract

Cited by 52 (26 self)
 Add to MetaCart
(Show Context)
This is a summary of the Ph.D. thesis of Tom Schrijvers [4]. Constraint Handling Rules (CHR) [3] is a rulebased language commonly embedded in a host language. It combines elements of Constraint Logic Programming and term rewriting. Several implementations of CHR exist: in Prolog, Haskell, Java and HAL. Typical applications of CHR are in the area of constraint solving, but currently CHR is also used in a wider range of applications, such as type checking, natural language processing and multiagent systems. In this work we contribute program analyses, program optimizations and extensions of the CHR language. For the optimized compilation of CHR we present several new optimizations: code specialization for ground constraints, antimonotonic delay avoidance, hashtable constraint stores and a new late storage optimization. These and other optimizations have been implemented in a new stateoftheart CHR system: the K.U.Leuven CHR system [5] which is currently available in SWI
A General Framework for Automatic Termination Analysis of Logic Programs
, 2000
"... This paper describes a general framework for automatic termination analysis of logic programs, where we understand by "termination" the finiteness of the LDtree constructed for the program and a given query. A general property of mappings from a certain subset of the branches of an infini ..."
Abstract

Cited by 49 (9 self)
 Add to MetaCart
This paper describes a general framework for automatic termination analysis of logic programs, where we understand by "termination" the finiteness of the LDtree constructed for the program and a given query. A general property of mappings from a certain subset of the branches of an infinite LDtree into a finite set is proved. From this result several termination theorems are derived, by using different finite sets. The first two are formulated for the predicate dependency and atom dependency graphs. Then a general result for the case of the querymapping pairs relevant to a program is proved (cf. [29,21]). The correctness of the TermiLog system described in [22] follows from it. In this system it is not possible to prove termination for programs involving arithmetic predicates, since the usual order for the integers is not wellfounded. A new method, which can be easily incorporated in TermiLog or similar systems, is presented, which makes it possible to prove termination for programs involving arithmetic predicates. It is based on combining a finite abstraction of the integers with the technique of the querymapping pairs, and is essentially capable of dividing a termination proof into several cases, such that a simple termination function suffices for each case. Finally several possible extensions are outlined. Key words termination of logic programs  abstract interpretation  constraints ? This research has been partially supported by grants from the Israel Science Foundation 2 Nachum Dershowitz et al. 1
Verifying Systems with Replicated Components in Murφ
, 1997
"... An extension to the Murphi verifier is presented to verify systems with replicated identical components. Although most systems are finitestate in nature, many of them are also designed to be scalable, so that a description gives a family of systems, each member of which has a different number of re ..."
Abstract

Cited by 48 (3 self)
 Add to MetaCart
An extension to the Murphi verifier is presented to verify systems with replicated identical components. Although most systems are finitestate in nature, many of them are also designed to be scalable, so that a description gives a family of systems, each member of which has a different number of replicated components. It is therefore desirable to be able to verify the entire family of systems, independent of the exact number of replicated components. The verification is performed by explicit state enumeration in an abstract state space where states do not record the exact numbers of components. We provide an extension to the existing Murphi language, by which a designer can easily specify a system in its concrete form. Through a new datatype, called RepetitiveID, a designer can suggest the use of this abstraction to verify a family of systems. First of all, Murphi automatically checks the soundness of this abstraction. Then it automatically translates the system description to an abstract ...