Architecture The Alma Abstract Architecture (AAA) is the virtual architecture used during the intermediate code generation phase of the Alma-0 compiler. The AAA combines the features of the abstract machines for imperative languages and for logic programming languages. The compiler compiles the Alma-0 programs into AAA programs. In a second phase the AAA instructions are translated into C statements. As the Alma-0 language itself, the AAA aims to combine the best of both worlds; elements were taken from virtual machines used to compile imperative languages (in particular the RISC architecture described in Wirth [1996, pp. 55--59], and from the WAM machine used to compile a logical language (see Ait-Kaci [1991]). Still, the AAA resembles most the virtual machines used in the compilation of imperative languages. The additions made to provide for the extensions of the Alma-0 language are ---the failure handling instructions ONFAIL, FAIL, 40 \Delta Krzysztof R. Apt et al ---the log ...

. Logic programs augmented with delay declarations form a higly expressive programming language in which dynamic networks of processes that communicate asynchronously by means of multiparty channels can be easily created. In this paper we study correctness these programs. In particular, we propose proof methods allowing us to deal with occur check freedom, absence of deadlock, absence of errors in presence of arithmetic relations, and termination. These methods turn out to be simple modifications of the corresponding methods dealing with Prolog programs. This allows us to derive correct delay declarations by analyzing Prolog programs. Finally, we point out difficulties concerning proofs of termination. Notes. The research of the first author was partly supported by the ESPRIT Basic Research Action 6810 (Compulog 2). This paper will appear as an invited lecture in: Proc. of the Fourth International Conference on Algebraic Methodology and Software Technology, (AMAST'95). 1 Introduction ...

We try to assess to what extent declarative programming can be realized in Prolog and which aspects of correctness of Prolog programs can be dealt with by means of declarative interpretation. More specifically, we shall discuss termination of Prolog programs, partial correctness, absence of errors and the safe use of negation. 1991 Mathematics Subject Classification: 68Q40, 68T15. CR Categories: F.3.2., F.4.1, H.3.3, I.2.3. Keywords and Phrases: declarative programming, Prolog programs, verification. Notes. This research was partly supported by the ESPRIT Basic Research Action 6810 (Compulog 2). This paper will appear as invited lecture in: Proc. of International Logic Programming Symposium (ILPS '93), The MIT Press, D. Miller (editor). It also appeared as a Technical Report No CT-93-06 in the ILLC Prepublication Series of the University of Amsterdam. 1

We show here that verification of Prolog programs can be systematically carried out within a simple framework which comprises syntactic analysis, declarative semantics, modes and types. We apply these techniques to study termination, partial correctness, occurcheck freedom, absence of errors and absence of floundering. Finally, we discuss which aspects of these techniques can be automated. Notes. This research was partly supported by the ESPRIT Basic Research Action 6810 (Compulog 2). A preliminary, shorter, version of this paper appeared as Apt [3]. 1 Introduction 1.1 Motivation Prolog is 20 years old and so is logic programming. However, they were developed separately and these two developments never really merged. The first track is best exemplified by Sterling and Shapiro [36], which puts emphasis on programming style and techniques, and the second by Lloyd [25], which concentrates on the theoretical foundations. As a result of these separate developments, until recently little...

Abstract. The most important open problem in the study of termination for logic programs is that of existential termination. Inthispaperwepresentapow erful transformational methodology that provides necessary (and, under some conditions, su cient) criteria for existential termination. The followed approach is to develop a suitable transformation from logic programs to Term Rewriting Systems (TRSs), such that proving termination of the obtained TRS implies existential termination of the original logic program. Thus, all the extensive amountofwork on termination for TRSs can be automatically used in the logic programming setting. Moreover, the approach isalsoabletocopewiththe dual notion of universal termination: in fact, a whole spectrum of termination properties, said k-termination,isinvestigated, of which universal and existential termination are the extremes. Also, a satisfactory treatment to the problem of termination for logic programming with negation is achieved. This way we provide a unique, uniform approachcovering all these di erent notions of termination. 1

Numerical computations form an essential part of almost any real-world program. Clearly, in order for a termination analyser to be of practical use it should contain a mechanism for inferring termination of such computations. However, this topic attracted less attention of the research community. In this work we concentrate on automatic termination inference for logic programs depending on numerical computations. Dershowitz et al. [8] showed that termination of general numerical computations, for instance on floating point numbers, may be counter-intuitive, i.e., the observed behaviour does not necessarily coincide with the theoretically expected one. Thus, we restrict ourselves to integer computations only. While discussing termination of integer computations the following question should be asked: what conditions on the queries should be assumed, such that the queries will terminate. We refer to this question as the termination inference...

Proving termination is one of the most intriguing problems of program verification. Recently, the study of termination of numerical programs led to the emerging of the adorning technique. This approach is based on the idea of distinguishing between different subsets of values for variables, and deriving piecewise level mappings based on these subsets. In the current paper we generalise the technique and consider symbolical computations. Our experience suggests that such a generalisation will allow automated tools to verify termination of examples that remain at the moment beyond their abilities.

this paper we show, among other things, that logical structures such as dierence lists have a natural counterpart in lazy functional programs; i.e. that most programs using dierence-lists are functional in nature. This shows immediately that many common non-well-moded programs are functional in nature and that well-modedness is thus not a necessary attribute of those logic programs behaving functionally. We do this by employing a straightforward { literal { translation of moded logic programs into Haskell, a lazy functional language

New, simple conditions are provided which allow the conclusion that in the case of several well-known Prolog programs the unification algorithm can be...

this domain. Then, in Section 5.5 we introduce a fundamental data structure of Prolog --- that of lists and provide several classic programs that use them. In the subsequent section an example of a program is given which illustrates Prolog's use of terms to represent complex objects. Then in Section 5.7 we introduce another important data structure --- that of binary trees and present various programs computing over them. We conclude 104 Introduction 105 the chapter by trying to assess in Section 5.8 the relevant aspects of programming in pure Prolog. We also summarize there the shortcomings of this subset of Prolog. 5.1 Introduction 5.1.1 Syntax When presenting pure Prolog programs we adhere to the usual syntactic conventions of Prolog. So each query and clause ends with the period "." and in the unit clauses " / " is omitted. Unit clauses are called facts and non-unit clauses are called