6,090 research outputs found
Using global analysis, partial specifications, and an extensible assertion language for program validation and debugging
We discuss a framework for the application of abstract interpretation as an aid during program development, rather than in the more traditional application of program optimization. Program validation and detection of errors is first performed statically by comparing (partial) specifications written in terms of assertions against information obtained from (global) static analysis of the program. The results of this process are expressed in the user assertion language. Assertions (or parts of assertions) which cannot be checked statically are translated into run-time tests. The framework allows the use of assertions to be optional. It also allows using very general properties in assertions, beyond the predefined set understandable by the static analyzer and including properties defined by user programs. We also report briefly on an implementation of the framework. The resulting tool generates and checks assertions for Prolog, CLP(R), and CHIP/CLP(fd) programs, and integrates compile-time and run-time checking in a uniform way. The tool allows using properties such as types, modes, non-failure, determinacy,
and computational cost, and can treat modules separately, performing incremental analysis
An overview of the ciao multiparadigm language and program development environment and its design philosophy
We describe some of the novel aspects and motivations behind
the design and implementation of the Ciao multiparadigm programming system. An important aspect of Ciao is that it provides the programmer with a large number of useful features from different programming paradigms and styles, and that the use of each of these features can be turned on and off at will for each program module. Thus, a given module may be using e.g. higher order functions and constraints, while another module may be using objects, predicates, and concurrency. Furthermore, the language is designed to be extensible in a simple and modular way. Another important aspect of Ciao is its programming environment, which provides a powerful preprocessor (with an associated assertion language) capable of statically finding non-trivial bugs, verifying that programs comply with specifications, and performing many types of program optimizations. Such optimizations produce code that is highly competitive with other dynamic languages or, when the highest levéis of optimization are used, even that of static languages, all while retaining the interactive development environment of a dynamic language. The environment also includes a powerful auto-documenter. The paper provides an informal overview of the language and program development environment. It aims at illustrating the design philosophy rather than at being exhaustive, which would be impossible in the format of a paper, pointing instead to the existing literature on the system
An Approach to Static Performance Guarantees for Programs with Run-time Checks
Instrumenting programs for performing run-time checking of properties, such
as regular shapes, is a common and useful technique that helps programmers
detect incorrect program behaviors. This is specially true in dynamic languages
such as Prolog. However, such run-time checks inevitably introduce run-time
overhead (in execution time, memory, energy, etc.). Several approaches have
been proposed for reducing such overhead, such as eliminating the checks that
can statically be proved to always succeed, and/or optimizing the way in which
the (remaining) checks are performed. However, there are cases in which it is
not possible to remove all checks statically (e.g., open libraries which must
check their interfaces, complex properties, unknown code, etc.) and in which,
even after optimizations, these remaining checks still may introduce an
unacceptable level of overhead. It is thus important for programmers to be able
to determine the additional cost due to the run-time checks and compare it to
some notion of admissible cost. The common practice used for estimating
run-time checking overhead is profiling, which is not exhaustive by nature.
Instead, we propose a method that uses static analysis to estimate such
overhead, with the advantage that the estimations are functions parameterized
by input data sizes. Unlike profiling, this approach can provide guarantees for
all possible execution traces, and allows assessing how the overhead grows as
the size of the input grows. Our method also extends an existing assertion
verification framework to express "admissible" overheads, and statically and
automatically checks whether the instrumented program conforms with such
specifications. Finally, we present an experimental evaluation of our approach
that suggests that our method is feasible and promising.Comment: 15 pages, 3 tables; submitted to ICLP'18, accepted as technical
communicatio
Abstract Diagnosis for Timed Concurrent Constraint programs
The Timed Concurrent Constraint Language (tccp in short) is a concurrent
logic language based on the simple but powerful concurrent constraint paradigm
of Saraswat. In this paradigm, the notion of store-as-value is replaced by the
notion of store-as-constraint, which introduces some differences w.r.t. other
approaches to concurrency. In this paper, we provide a general framework for
the debugging of tccp programs. To this end, we first present a new compact,
bottom-up semantics for the language that is well suited for debugging and
verification purposes in the context of reactive systems. We also provide an
abstract semantics that allows us to effectively implement debugging algorithms
based on abstract interpretation. Given a tccp program and a behavior
specification, our debugging approach automatically detects whether the program
satisfies the specification. This differs from other semiautomatic approaches
to debugging and avoids the need to provide symptoms in advance. We show the
efficacy of our approach by introducing two illustrative examples. We choose a
specific abstract domain and show how we can detect that a program is
erroneous.Comment: 16 page
- âŠ