30,467 research outputs found
A Backward Analysis for Constraint Logic Programs
One recurring problem in program development is that of understanding how to
re-use code developed by a third party. In the context of (constraint) logic
programming, part of this problem reduces to figuring out how to query a
program. If the logic program does not come with any documentation, then the
programmer is forced to either experiment with queries in an ad hoc fashion or
trace the control-flow of the program (backward) to infer the modes in which a
predicate must be called so as to avoid an instantiation error. This paper
presents an abstract interpretation scheme that automates the latter technique.
The analysis presented in this paper can infer moding properties which if
satisfied by the initial query, come with the guarantee that the program and
query can never generate any moding or instantiation errors. Other applications
of the analysis are discussed. The paper explains how abstract domains with
certain computational properties (they condense) can be used to trace
control-flow backward (right-to-left) to infer useful properties of initial
queries. A correctness argument is presented and an implementation is reported.Comment: 32 page
Combining Forward and Backward Abstract Interpretation of Horn Clauses
Alternation of forward and backward analyses is a standard technique in
abstract interpretation of programs, which is in particular useful when we wish
to prove unreachability of some undesired program states. The current
state-of-the-art technique for combining forward (bottom-up, in logic
programming terms) and backward (top-down) abstract interpretation of Horn
clauses is query-answer transformation. It transforms a system of Horn clauses,
such that standard forward analysis can propagate constraints both forward, and
backward from a goal. Query-answer transformation is effective, but has issues
that we wish to address. For that, we introduce a new backward collecting
semantics, which is suitable for alternating forward and backward abstract
interpretation of Horn clauses. We show how the alternation can be used to
prove unreachability of the goal and how every subsequent run of an analysis
yields a refined model of the system. Experimentally, we observe that combining
forward and backward analyses is important for analysing systems that encode
questions about reachability in C programs. In particular, the combination that
follows our new semantics improves the precision of our own abstract
interpreter, including when compared to a forward analysis of a
query-answer-transformed system.Comment: Francesco Ranzato. 24th International Static Analysis Symposium
(SAS), Aug 2017, New York City, United States. Springer, Static Analysi
Probabilistic Programming Concepts
A multitude of different probabilistic programming languages exists today,
all extending a traditional programming language with primitives to support
modeling of complex, structured probability distributions. Each of these
languages employs its own probabilistic primitives, and comes with a particular
syntax, semantics and inference procedure. This makes it hard to understand the
underlying programming concepts and appreciate the differences between the
different languages. To obtain a better understanding of probabilistic
programming, we identify a number of core programming concepts underlying the
primitives used by various probabilistic languages, discuss the execution
mechanisms that they require and use these to position state-of-the-art
probabilistic languages and their implementation. While doing so, we focus on
probabilistic extensions of logic programming languages such as Prolog, which
have been developed since more than 20 years
Generalization Strategies for the Verification of Infinite State Systems
We present a method for the automated verification of temporal properties of
infinite state systems. Our verification method is based on the specialization
of constraint logic programs (CLP) and works in two phases: (1) in the first
phase, a CLP specification of an infinite state system is specialized with
respect to the initial state of the system and the temporal property to be
verified, and (2) in the second phase, the specialized program is evaluated by
using a bottom-up strategy. The effectiveness of the method strongly depends on
the generalization strategy which is applied during the program specialization
phase. We consider several generalization strategies obtained by combining
techniques already known in the field of program analysis and program
transformation, and we also introduce some new strategies. Then, through many
verification experiments, we evaluate the effectiveness of the generalization
strategies we have considered. Finally, we compare the implementation of our
specialization-based verification method to other constraint-based model
checking tools. The experimental results show that our method is competitive
with the methods used by those other tools. To appear in Theory and Practice of
Logic Programming (TPLP).Comment: 24 pages, 2 figures, 5 table
Size-Change Termination, Monotonicity Constraints and Ranking Functions
Size-Change Termination (SCT) is a method of proving program termination
based on the impossibility of infinite descent. To this end we may use a
program abstraction in which transitions are described by monotonicity
constraints over (abstract) variables. When only constraints of the form x>y'
and x>=y' are allowed, we have size-change graphs. Both theory and practice are
now more evolved in this restricted framework then in the general framework of
monotonicity constraints. This paper shows that it is possible to extend and
adapt some theory from the domain of size-change graphs to the general case,
thus complementing previous work on monotonicity constraints. In particular, we
present precise decision procedures for termination; and we provide a procedure
to construct explicit global ranking functions from monotonicity constraints in
singly-exponential time, which is better than what has been published so far
even for size-change graphs.Comment: revised version of September 2
- …