Machine or WAM. Section 5 describes some optimizations and shows how Mercury handles I/O. Section 6 gives the current state of the Mercury system while section 7 presents performance results. 2. The Mercury language Syntactically, Mercury is similar to Prolog with additional declarations, partly because Prolog syntax is standard in the logic programming community and partly because this made it simple to execute Mercury programs using Prolog systems early in our project. Semantically, however, Mercury is very different from Prolog. Mercury is a pure logic programming language with a well-defined declarative semantics. Like Godel [14], Mercury provides declarative replacements for Prolog 's non-logical features. Unlike Godel, Mercury does not retain any non-logical features; in Mercury even I/O is declarative. Mercury is designed to appeal to at least two groups of programmers. One group is those with backgrounds in imperative languages such as C who are looking for a higher level an...

. We consider how mode (such as input and output) and termination properties of typed higher-order constraint logic programming languages may be declared and checked effectively. The systems that we present have been validated through an implementation and numerous case studies. 1 Introduction Just like other paradigms logic programming benefits tremendously from types. Perhaps most importantly, types allow the early detection of errors when a program is checked against a type specification. With some notable exceptions most type systems proposed for logic programming languages to date (see [18]) are concerned with the declarative semantics of programs, for example, in terms of many-sorted, order-sorted, or higher-order logic. Operational properties of logic programs which are vital for their correctness can thus neither be expressed nor checked and errors will remain undetected. In this paper we consider how the declaration and checking of mode (such as input and output) and termina...

This paper investigates the role of coroutining in the termination of logic programs. We define a variant of SLD resolution, in which the execution of atoms may be suspended indefinitely, and give some basic results concerning success, finite failure and floundering. Next we discuss how correct procedures can be combined to form new procedures using disjunction, conjunction and recursion. We argue that modes are crucial to reasoning about termination and show that cyclic modes are the basic reason for conjunctions looping. When recursion is used we identify another cause of loops: speculative binding of output variables. That is, binding output variables before it is known that a solution to a subcomputation exists. Keywords: mode, flounder, Prolog, stream and-parallelism -- 1 -- 1 Introduction

. Precise mode information is important for compiler optimisations and in program development tools. Within the framework of abstract compilation, the precision of a mode analysis depends, in part, on the expressiveness of the abstract domain and its associated abstraction function. This paper considers abstract domains for polymorphically typed logic programs and shows how specialised domains may be constructed for each type in the program. These domains capture the degree of instantiation to a high level of precision. By providing a generic definition of abstract unication, the abstraction of a program using these domains is formalised. The domain construction procedure is fully implemented using the Godel language and tested on a number of example programs to demonstrate the viability of the approach. Note: Some proofs have been omitted for space reasons. They can be found in the full version of this paper [17]. 1 Introduction 1.1 Background Typed logic programming languages su...

. In this paper, we describe a binding-time analysis (BTA) for a statically typed and strongly moded pure logic programming language, in casu Mercury. Binding-time analysis is the key concept in achieving o-line program specialisation: the analysis starts from a description of the program's input available for specialisation, and propagates this information throughout the program, deriving directives for when and how to perform specialisation. 1

this paper as an example. However, Mercury is by no means the only possible language design that fits within our proposal's framework. 2.1 A strong type system

. Functional logic languages amalgamate functional and logic programming paradigms. They can be efficiently implemented by extending techniques known from logic programming. In this paper we show how global information about the call modes of functions can be used to optimize the compilation of functional logic programs. Since mode information has been successfully used to improve the implementation of pure logic programs and these techniques can be applied to implementations of functional logic programs as well, we concentrate on optimizations which are unique to the operational semantics of functional logic programs. We define a suitable notion of modes for functional logic programs and present compile-time techniques to optimize the normalization process during the execution of functional logic programs. 1 Introduction In recent years, a lot of proposals have been made to amalgamate functional and logic programming languages [7, 17]. Functional logic languages with a so...

Abstract not found

Abstract Most deductive databases impose restrictions on the terms that can be used in them: they require that generated tuples be fully ground, i.e. contain no variables. Without this restriction, query evaluation of general programs needs subsumption tests in order to terminate correctly, and subsumption tests are expensive. We study a class of programs that can handle terms with both variables and function symbols but for which subsumption tests are not necessary. This class is based on the notion of modes, which generalise adornments by not requiring that "bound " be synonymous with "ground". We show how programs in this class may be recognized and how they should be transformed into an executable form, and then prove that bottom-up evaluation of the resulting programs does not require subsumption tests. 1 Introduction Deductive databases are logic programming systems designed for applications that handle large amounts of data. Since logic programs can be viewed as an extension of relational databases and since relational databases handle large amounts of data, deductive database researchers usually try to use techniques developed for relational systems whenever possible. One consequence of this tendency is that unlike implementations of general-purpose logic programming systems, most deductive database systems use bottom-up evaluation methods.

In this thesis we look at mode analysis of logic programs. Being based on the mathematical formalism of predicate logic, logic programs have no a priori notion of data flow --- a single logic program may run in multiple modes where each mode describes, or prescribes, a pattern of data flow.