Context-Sensitive Multivariant Assertion Checking in Modular Programs

Pietrzak, Paweł; Fernández, Justino; Puebla, Germán; Hermenegildo, Manuel V.

doi:10.1007/11916277_27

Cited by 9 publications

(13 citation statements)

References 14 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…nation, and bounds on the execution time (Mera et al 2008), and the consumption of a large class of user-defined resources (Navas et al 2007). Assertion checking in CiaoPP is also module-aware (Pietrzak et al 2006;Pietrzak et al 2008). Finally, the information from analysis can be used to optimize the program in later compilation stages, as we will discuss later.…”

Section: The Ciao Unified Assertion Frameworkmentioning

confidence: 99%

An overview of Ciao and its design philosophy

Hermenegildo¹,

Bueno²,

Carro³

et al. 2011

Theory and Practice of Logic Programming

111

118

View full text Add to dashboard Cite

We provide an overall description of the Ciao multiparadigm programming system emphasizing some of the novel aspects and motivations behind its design and implementation. An important aspect of Ciao is that, in addition to supporting logic programming (and, in particular, Prolog), 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 (including those of Prolog) 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 assignment, predicates, Prolog meta-programming, 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 optimizations (including automatic parallelization). Such optimizations produce code that is highly competitive with other dynamic languages or, with the (experimental) optimizing compiler, even that of static languages, all while retaining the flexibility and interactive development of a dynamic language. This compilation architecture supports modularity and separate compilation throughout. The environment also includes a powerful auto-documenter and a unit testing framework, both closely integrated with the assertion system. 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 a single journal paper, pointing instead to previous Ciao literature.

show abstract

Section: The Ciao Unified Assertion Frameworkmentioning

confidence: 99%

An overview of Ciao and its design philosophy

Hermenegildo¹,

Bueno²,

Carro³

et al. 2011

Theory and Practice of Logic Programming

111

118

View full text Add to dashboard Cite

show abstract

“…If no assertions are present in the module for exported predicates or if the preconditions in such assertions do not match the calling patterns the module will simply be entered and analyzed during modular analysis, as described in Section 3 (see also (Puebla et al 2004;Pietrzak et al 2006)). However, if suitable parametric assertions are present, assume that both precondition P re and postcondition P ost contain parameters A and B respectively.…”

Section: Using Parametric Type Assertions In Modular Analysismentioning

confidence: 99%

“…In Ciao, a multi-variant, context sensitive analysis engine ) is used which is parametric w.r.t. the abstract domain of interest and which can analyze Puebla et al 2004) and check (Pietrzak et al 2006) modular programs. Unfortunately, in this setting, the analysis of real-life, modular Prolog programs, using regular types turns out to be too expensive in practice.…”

Section: Introductionmentioning

confidence: 99%

“…The main application of our analysis is in verification of programs with respect to a partial specification written in the form of a number of type assertions and type definitions (see Pietrzak et al 2006)). Note that any assertion present in the program must refer to types which are defined in user or library modules anyway, and therefore in this case we may not lose many opportunities for verifying assertions.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

A practical type analysis for verification of modular prolog programs

Pietrzak

Fernández²,

Puebla

et al. 2008

Proceedings of the 2008 ACM SIGPLAN Symposium on Partial Evaluation and Semantics-Based Program Manipulation

Self Cite

View full text Add to dashboard Cite

Regular types are a powerful tool for computing very precise descriptive types for logic programs. However, in the context of reallife, modular Prolog programs, the accurate results obtained by regular types often come at the price of efficiency. In this paper we propose a combination of techniques aimed at improving analysis efficiency in this context. As a first technique we allow optionally reducing the accuracy of inferred types by using only the types defined by the user or present in the libraries. We claim that, for the purpose of verifying type signatures given in the form of assertions the precision obtained using this approach is sufficient, and show that analysis times can be reduced significantly. Our second technique is aimed at dealing with situations where we would like to limit the amount of reanalysis performed, especially for library modules. Borrowing some ideas from polymorphic type systems, we show how to solve the problem by admitting parameters in type specifications. This allows us to compose new call patterns with some precomputed analysis info without losing any information. We argue that together these two techniques contribute to the practical and scalable analysis and verification of types in Prolog programs.

show abstract

“…M. Klemen et al 1997;Hermenegildo et al 1999;Laï 2000;Pietrzak et al 2006) in (constraint) logic languages, soft- (Cartwright and Fagan 1991;Tobin-Hochstadt and Felleisen 2008) and gradual- (Siek and Taha 2006) typing in functional languages, and contract-based approaches (Leavens et al 2007;Lamport and Paulson 1999;Nguyen et al 2014) in imperative languages. A trait that many of these approaches share is that some parts of the specifications may be the subject of run-time checking (e.g., those cannot be discharged statically in the case of systems that support this functionality).…”

mentioning

confidence: 99%

Static Performance Guarantees for Programs with Runtime Checks

Klemen

Stulova

López-García

et al. 2018

Proceedings of the 20th International Symposium on Principles and Practice of Declarative Programming

Self Cite

View full text Add to dashboard Cite

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.

show abstract

Context-Sensitive Multivariant Assertion Checking in Modular Programs

Cited by 9 publications

References 14 publications

An overview of Ciao and its design philosophy

An overview of Ciao and its design philosophy

A practical type analysis for verification of modular prolog programs

Static Performance Guarantees for Programs with Runtime Checks

Contact Info

Product

Resources

About