5,741 research outputs found
Correctness and completeness of logic programs
We discuss proving correctness and completeness of definite clause logic
programs. We propose a method for proving completeness, while for proving
correctness we employ a method which should be well known but is often
neglected. Also, we show how to prove completeness and correctness in the
presence of SLD-tree pruning, and point out that approximate specifications
simplify specifications and proofs.
We compare the proof methods to declarative diagnosis (algorithmic
debugging), showing that approximate specifications eliminate a major drawback
of the latter. We argue that our proof methods reflect natural declarative
thinking about programs, and that they can be used, formally or informally, in
every-day programming.Comment: 29 pages, 2 figures; with editorial modifications, small corrections
and extensions. arXiv admin note: text overlap with arXiv:1411.3015. Overlaps
explained in "Related Work" (p. 21
Logic Programming as Constructivism
The features of logic programming that
seem unconventional from the viewpoint of classical logic
can be explained in terms of constructivistic logic. We
motivate and propose a constructivistic proof theory of
non-Horn logic programming. Then, we apply this formalization
for establishing results of practical interest.
First, we show that 'stratification can be motivated in a
simple and intuitive way. Relying on similar motivations,
we introduce the larger classes of 'loosely stratified' and
'constructively consistent' programs. Second, we give a
formal basis for introducing quantifiers into queries and
logic programs by defining 'constructively domain
independent* formulas. Third, we extend the Generalized
Magic Sets procedure to loosely stratified and constructively
consistent programs, by relying on a 'conditional
fixpoini procedure
Proving Correctness and Completeness of Normal Programs - a Declarative Approach
We advocate a declarative approach to proving properties of logic programs.
Total correctness can be separated into correctness, completeness and clean
termination; the latter includes non-floundering. Only clean termination
depends on the operational semantics, in particular on the selection rule. We
show how to deal with correctness and completeness in a declarative way,
treating programs only from the logical point of view. Specifications used in
this approach are interpretations (or theories). We point out that
specifications for correctness may differ from those for completeness, as
usually there are answers which are neither considered erroneous nor required
to be computed.
We present proof methods for correctness and completeness for definite
programs and generalize them to normal programs. For normal programs we use the
3-valued completion semantics; this is a standard semantics corresponding to
negation as finite failure. The proof methods employ solely the classical
2-valued logic. We use a 2-valued characterization of the 3-valued completion
semantics which may be of separate interest. The presented methods are compared
with an approach based on operational semantics. We also employ the ideas of
this work to generalize a known method of proving termination of normal
programs.Comment: To appear in Theory and Practice of Logic Programming (TPLP). 44
page
Applying Formal Methods to Networking: Theory, Techniques and Applications
Despite its great importance, modern network infrastructure is remarkable for
the lack of rigor in its engineering. The Internet which began as a research
experiment was never designed to handle the users and applications it hosts
today. The lack of formalization of the Internet architecture meant limited
abstractions and modularity, especially for the control and management planes,
thus requiring for every new need a new protocol built from scratch. This led
to an unwieldy ossified Internet architecture resistant to any attempts at
formal verification, and an Internet culture where expediency and pragmatism
are favored over formal correctness. Fortunately, recent work in the space of
clean slate Internet design---especially, the software defined networking (SDN)
paradigm---offers the Internet community another chance to develop the right
kind of architecture and abstractions. This has also led to a great resurgence
in interest of applying formal methods to specification, verification, and
synthesis of networking protocols and applications. In this paper, we present a
self-contained tutorial of the formidable amount of work that has been done in
formal methods, and present a survey of its applications to networking.Comment: 30 pages, submitted to IEEE Communications Surveys and Tutorial
Classes of Terminating Logic Programs
Termination of logic programs depends critically on the selection rule, i.e.
the rule that determines which atom is selected in each resolution step. In
this article, we classify programs (and queries) according to the selection
rules for which they terminate. This is a survey and unified view on different
approaches in the literature. For each class, we present a sufficient, for most
classes even necessary, criterion for determining that a program is in that
class. We study six classes: a program strongly terminates if it terminates for
all selection rules; a program input terminates if it terminates for selection
rules which only select atoms that are sufficiently instantiated in their input
positions, so that these arguments do not get instantiated any further by the
unification; a program local delay terminates if it terminates for local
selection rules which only select atoms that are bounded w.r.t. an appropriate
level mapping; a program left-terminates if it terminates for the usual
left-to-right selection rule; a program exists-terminates if there exists a
selection rule for which it terminates; finally, a program has bounded
nondeterminism if it only has finitely many refutations. We propose a
semantics-preserving transformation from programs with bounded nondeterminism
into strongly terminating programs. Moreover, by unifying different formalisms
and making appropriate assumptions, we are able to establish a formal hierarchy
between the different classes.Comment: 50 pages. The following mistake was corrected: In figure 5, the first
clause for insert was insert([],X,[X]
- âŠ