Results 1  10
of
156
leanTAP: Lean Tableaubased Deduction
 Journal of Automated Reasoning
, 1995
"... . "prove((E,F),A,B,C,D) : !, prove(E,[FA],B,C,D). prove((E;F),A,B,C,D) : !, prove(E,A,B,C,D), prove(F,A,B,C,D). prove(all(H,I),A,B,C,D) : !, "+length(C,D), copyterm((H,I,C),(G,F,C)), append(A,[all(H,I)],E), prove(F,E,B,[GC],D). prove(A,,[CD],,) : ((A= (B); (A)=B)) ? (unify ..."
Abstract

Cited by 79 (11 self)
 Add to MetaCart
. "prove((E,F),A,B,C,D) : !, prove(E,[FA],B,C,D). prove((E;F),A,B,C,D) : !, prove(E,A,B,C,D), prove(F,A,B,C,D). prove(all(H,I),A,B,C,D) : !, "+length(C,D), copyterm((H,I,C),(G,F,C)), append(A,[all(H,I)],E), prove(F,E,B,[GC],D). prove(A,,[CD],,) : ((A= (B); (A)=B)) ? (unify(B,C); prove(A,[],D,,)). prove(A,[EF],B,C,D) : prove(E,F,[AB],C,D)." implements a firstorder theorem prover based on freevariable semantic tableaux. It is complete, sound, and efficient. 1 Introduction The Prolog program listed in the abstract implements a complete and sound theorem prover for firstorder logic; it is based on freevariable semantic tableaux (Fitting, 1990). We call this lean deduction: the idea is to achieve maximal efficiency from minimal means. We will see that the above program is indeed very efficientnot although but because it is extremely short and compact. Our approach surely does not lead to a deduction system which is superior to highly sophisticated systems li...
Specifications Are (Preferably) Executable
, 1992
"... ion of the Specification Borrowing a saying of Einstein's, I maintain that specifications should be as abstract as possible, but not more abstract. I see three limitations to the degree of abstraction. First, a specification as an adequate formalization of the requirements cannot be more abstr ..."
Abstract

Cited by 62 (0 self)
 Add to MetaCart
ion of the Specification Borrowing a saying of Einstein's, I maintain that specifications should be as abstract as possible, but not more abstract. I see three limitations to the degree of abstraction. First, a specification as an adequate formalization of the requirements cannot be more abstract than the requirements themselves. If a specific algorithm is required, this algorithm must be specified. This argument applies as well to nonfunctional requirements constraining possible implementations. Some constraints can appear as comments in specifications, e.g. the requirement that a specific language should be used for the implementation. Other constraints, however, must be concretely specified, e.g. the requirement that the future software system has to adhere to the data structures of a given interface. The second limitation to abstraction arises when we make formal specifications executable. Even if the degree of abstraction of the data structures and the algorithms stays the same,...
Optimal NonDeterministic Functional Logic Computations
 In Proc. International Conference on Algebraic and Logic Programming (ALP’97
, 1298
"... Abstract. We show that nondeterminism simplifies coding certain problems into programs. We define a nonconfluent, but wellbehaved class of rewrite systems for supporting nondeterministic computations in functional logic programming. We show the benefits of using this class on a few examples. We ..."
Abstract

Cited by 61 (34 self)
 Add to MetaCart
Abstract. We show that nondeterminism simplifies coding certain problems into programs. We define a nonconfluent, but wellbehaved class of rewrite systems for supporting nondeterministic computations in functional logic programming. We show the benefits of using this class on a few examples. We define a narrowing strategy for this class of systems and prove that our strategy is sound, complete, and optimal, modulo nondeterministic choices, for appropriate definitions of these concepts. We compare our strategy with related work and show that our overall approach is fully compatible with the current proposal of a universal, broadbased functional logic language. 1
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 49 (4 self)
 Add to MetaCart
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.
Efficient Relational Calculation for Software Analysis
 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING
, 2005
"... Calculating with graphs and relations has many applications in the analysis of software systems, for example, the detection of design patterns or patterns of problematic design and the computation of design metrics. These applications require an expressive query language, in particular, for the dete ..."
Abstract

Cited by 45 (1 self)
 Add to MetaCart
Calculating with graphs and relations has many applications in the analysis of software systems, for example, the detection of design patterns or patterns of problematic design and the computation of design metrics. These applications require an expressive query language, in particular, for the detection of graph patterns, and an efficient evaluation of the queries even for large graphs. In this paper, we introduce RML, a simple language for querying and manipulating relations based on predicate calculus, and CrocoPat, an interpreter for RML programs. RML is general because it enables the manipulation not only of graphs (i.e., binary relations), but of relations of arbitrary arity. CrocoPat executes RML programs efficiently because it internally represents relations as binary decision diagrams, a data structure that is wellknown as a compact representation of large relations in computeraided verification. We evaluate RML by giving example programs for several software analyses and CrocoPat by comparing its performance with calculators for binary relations, a Prolog system, and a relational database management system.
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 41 (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
Applying Techniques to Skeletons
 Constructing Logic Programs
, 1993
"... This paper concerns our research on developing a theory and methodology appropriate for systematically building complicated Prolog programs. Programs are constructed procedurally from standard components. We identify skeletons, basic Prolog programs with a wellunderstood control flow, and technique ..."
Abstract

Cited by 36 (7 self)
 Add to MetaCart
This paper concerns our research on developing a theory and methodology appropriate for systematically building complicated Prolog programs. Programs are constructed procedurally from standard components. We identify skeletons, basic Prolog programs with a wellunderstood control flow, and techniques, standard Prolog programming practices, as basic components. Applying a technique to a skeleton creates an extension of the skeleton. Complicated programs are built by choosing a skeleton and repeatedly applying techniques. Separate extensions of the same skeleton can be composed into a single program, simplifying the process of program development. We describe our application of skeletons and techniques within the framework of Shapiro's Model Inference System. 1.1 INTRODUCTION
SchemaBased Transformations of Logic Programs
 In Proceedings of the International Workshop on Logic Program Synthesis and Transformation (LoPSTr'92
, 1991
"... ion Selection Specialization P1/A1 Pn/An S1/G 1 Sn/G n S/G P/A 8 Abstraction For each program P i (i=1, ... , n) we identify a program schema S i which describes P i abstractly. This abstraction generates a set of substitutions q i for schema variables. The same abstraction leads from the lite ..."
Abstract

Cited by 34 (8 self)
 Add to MetaCart
ion Selection Specialization P1/A1 Pn/An S1/G 1 Sn/G n S/G P/A 8 Abstraction For each program P i (i=1, ... , n) we identify a program schema S i which describes P i abstractly. This abstraction generates a set of substitutions q i for schema variables. The same abstraction leads from the literals A i to the abstract literals G i . In short, the abstraction step replaces each term P i /A i by its abstraction S i /G i , and we have P i /A i = S i q i /G i q i . Selection Transformation schemata transform the set of abstract terms {S 1 /G 1 , ... , S n /G n } into an abstract term S/G, i.e. a transformation schema is defined as {S 1 /G 1 , ... , S n /G n, S/G}. In general there are several transformation schemata which have {S 1 /G 1 , ... , S n /G n } as input. We select the transformation schema which generates a desired output program schema S together with an abstract literal G. Specialization We apply the substitution q = q 1 ... q n to S/G to get the transformed pr...