Results 1  10
of
15
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.
A SemiFunctional Implementation of a HigherOrder Logic Programming Language
 Topics in Advanced Language Implementation
, 1991
"... ions *) and varbind = Varbind of string * term (* Variable binders , Type *) In the implementation of the term language and the type checker, we have two constants type and pi. And, yes, type is a type, though this could be avoided by introducing universes (see [16]) without any changes to the code ..."
Abstract

Cited by 35 (0 self)
 Add to MetaCart
ions *) and varbind = Varbind of string * term (* Variable binders , Type *) In the implementation of the term language and the type checker, we have two constants type and pi. And, yes, type is a type, though this could be avoided by introducing universes (see [16]) without any changes to the code of the unifier. As is customary, we use A ! B as an abbreviation for \Pix : A: B if x does not occur free in B. Also, however, \Pix : A: B is an abbreviation for the application pi A (x : A: B). In our formulation, then, the constant pi has type \PiA : type: ((A ! type) ! type). As an example consider a predicate constant eq of type \PiA : type: A ! A ! o (where o is the type of formulas as indicated in Section 9). The single clause eqAM M: correctly models equality, that is, a goal of the form eq AM N will succeed if M and N are unifiable. The fact that unification now has to branch can be seen by considering the goal eq int (F 1 1) 1 which has three solutions for the functional logic var...
Practical RefinementType Checking
, 1997
"... Refinement types allow many more properties of programs to be expressed and statically checked than conventional type systems. We present a practical algorithm for refinementtype checking in a calculus enriched with refinementtype annotations. We prove that our basic algorithm is sound and comple ..."
Abstract

Cited by 34 (1 self)
 Add to MetaCart
Refinement types allow many more properties of programs to be expressed and statically checked than conventional type systems. We present a practical algorithm for refinementtype checking in a calculus enriched with refinementtype annotations. We prove that our basic algorithm is sound and complete, and show that every term which has a refinement type can be annotated as required by our algorithm. Our positive experience with an implementation of an extension of this algorithm to the full core language of Standard ML demonstrates that refinement types can be a practical program development tool in a realistic programming language. The required refinement type definitions and annotations are not much of a burden and serve as formal, machinechecked explanations of code invariants which otherwise would remain implicit. 1 Introduction The advantages of staticallytyped programming languages are well known, and have been described many times (e.g. see [Car97]). However, conventional ty...
From Interpreter to Logic Engine by Defunctionalization
, 2004
"... Starting from a continuationbased interpreter for a simple logic programming language, propositional Prolog with cut, we derive the corresponding logic engine in the form of an abstract machine. The derivation originates in previous work (our article at PPDP 2003) where it was applied to the la ..."
Abstract

Cited by 19 (12 self)
 Add to MetaCart
Starting from a continuationbased interpreter for a simple logic programming language, propositional Prolog with cut, we derive the corresponding logic engine in the form of an abstract machine. The derivation originates in previous work (our article at PPDP 2003) where it was applied to the lambdacalculus. The key transformation here is Reynolds's defunctionalization that transforms a tailrecursive, continuationpassing interpreter into a transition system, i.e., an abstract machine. Similar denotational and operational semantics were studied by de Bruin and de Vink (their article at TAPSOFT 1989), and we compare their study with our derivation. Additionally, we present a directstyle interpreter of propositional Prolog expressed with control operators for delimited continuations.
Making Exhaustive Search Programs Deterministic, Part II
 New Generation Computing
"... This paper complements the previous paper \Making Exhaustive Search Programs Deterministic" which showed a systematic method for compiling a Hornclause program for exhaustive search into a GHC program or a Prolog program with no backtracking. This time we present a systematic method for deriving a ..."
Abstract

Cited by 18 (4 self)
 Add to MetaCart
This paper complements the previous paper \Making Exhaustive Search Programs Deterministic" which showed a systematic method for compiling a Hornclause program for exhaustive search into a GHC program or a Prolog program with no backtracking. This time we present a systematic method for deriving a deterministic logic program that simulates coroutining execution of a generateandtest logic program. The class of compilable programs is suciently general, and compiled programs proved to be ecient. The method can also be viewed as suggesting a method of compiling a naive logic program into (very) lowlevel languages.
Prolog's Control Constructs in a Functional . . .
 INTERNATIONAL JOURNAL OF FOUNDATIONS OF COMPUTER SCIENCE
"... The purpose of this article is twofold. First, we show that Prolog's control constructs can be smoothly integrated into a functional language like Haskell. The resulting `language', termed embedded Prolog, incorporates many of the features prescribed by the Prolog ISO standard: control constructs ..."
Abstract

Cited by 13 (5 self)
 Add to MetaCart
The purpose of this article is twofold. First, we show that Prolog's control constructs can be smoothly integrated into a functional language like Haskell. The resulting `language', termed embedded Prolog, incorporates many of the features prescribed by the Prolog ISO standard: control constructs including the cut, all solution collecting functions, and error handling facilities. Embedded Prolog lacks some concepts such as logical variables but it inherits all of Haskell's strengths, eg static polymorphic typing, higher order functions etc. Technically, the integration is achieved using monads and monad transformers. One of the main innovations is the de nition of a backtracking monad transformer, which allows us to combine backtracking with exception handling and interaction. Second, we work towards an axiomatization of the operations, through which the computational features are accessed. Equations are used to lay down the meaning of the various operations and their interrelations enabling the programmer to reason about programs in a simple calculational style. The axiomatization is applied to show that each nite computation has a simple canonical form.
A Unifying Approach to GoalDirected Evaluation
 New Generation Computing
, 2001
"... Goaldirected evaluation, as embodied in Icon and Snobol, is built on the notions of backtracking and of generating successive results, and therefore it has always been something of a challenge to specify and implement. In this article, we address this challenge using computational monads and partia ..."
Abstract

Cited by 12 (4 self)
 Add to MetaCart
Goaldirected evaluation, as embodied in Icon and Snobol, is built on the notions of backtracking and of generating successive results, and therefore it has always been something of a challenge to specify and implement. In this article, we address this challenge using computational monads and partial evaluation. We consider a subset of Icon and we specify it with a monadic semantics and a list monad. We then consider a spectrum of monads that also fit the bill, and we relate them to each other. For example, we derive a continuation monad as a Church encoding of the list monad. The resulting semantics coincides with Gudeman's continuation semantics of Icon. We then compile Icon programs by specializing their interpreter (i.e., by using the first Futamura projection), using typedirected partial evaluation. Through various back ends, including a runtime code generator, we generate ML code, C code, and OCaml byte code. Bindingtime analysis and partial evaluation of the continuationbased interpreter automatically give rise to C programs that coincide with the result of Proebsting's optimized compiler.
Compiling Mercury to highlevel C code
 Proceedings of the 2002 International Conference on Compiler Construction
, 2001
"... Many logic programming implementations compile to C, but they compile to very lowlevel C, and thus discard many of the advantages of compiling to a highlevel language. We describe an alternative approach to compiling logic programs to C, based on continuation passing, that we have used in a new ba ..."
Abstract

Cited by 8 (4 self)
 Add to MetaCart
Many logic programming implementations compile to C, but they compile to very lowlevel C, and thus discard many of the advantages of compiling to a highlevel language. We describe an alternative approach to compiling logic programs to C, based on continuation passing, that we have used in a new backend for the Mercury compiler. The new approach compiles to much higherlevel C code, which means the compiler backend and runtime system can be considerably simpler.
A Pragmatic Approach to Reuse in Tactical Theorem Proving
, 2001
"... In interactive theorem proving, tactics and tacticals have been introduced to automate proof search. In this scenario, user interaction traditionally is restricted to the mode in which the user decides which tactic to apply on the toplevel, without being able to interact with the tactic once it ..."
Abstract

Cited by 8 (3 self)
 Add to MetaCart
In interactive theorem proving, tactics and tacticals have been introduced to automate proof search. In this scenario, user interaction traditionally is restricted to the mode in which the user decides which tactic to apply on the toplevel, without being able to interact with the tactic once it has begun running. We propose a technique to allow the implementation of derivational analogy in tactical theorem proving. Instead of replaying tactics including backtracked dead ends our framework makes choice points in tactics explicit and thus avoids dead ends when reusing tactics. Additionally users can override choices a tactic has made or add additional steps to a derivation without terminating the tactic. The technique depends on an ecient replay of tactic executions without repeating search that the original computation may have involved. 1