On the Operational Semantics of the Algebraic and ... - Semantic Scholar

Report 1 Downloads 185 Views
On the Operational Semantics of the Algebraic and Logic Programming Language LPG Didier Bert and Rachid Echahed IMAG-LGI, CNRS, BP 53, 38041 Grenoble cedex 9, France Email: fbert,[email protected]

Abstract. This paper gives a brief description of the recent improvements of lpg, a programming language that integrates algebraic and logic programming paradigms. In this language, functions are de ned by means of constructor-based conditional term rewriting systems and predicates are de ned by means of Horn clauses where the bodies may contain classical literals as well as equations and negations of equations (disequations). The operational semantics of lpg is based on an extension of ?resolution which deals with equations and disequations by using a narrowing-based algorithm. We investigate such a narrowing-based algorithm for solving equations and disequations and give new sucient conditions that ensure the completeness of narrowing strategies, in presence of conditional term rewrite systems. Similarities and di erencies with other logic and functional languages are pointed out. S LD

1 Introduction After the proposal of the language loglisp by Robinson and Sibert [22], many languages have been proposed to combine functional and logic programming paradigms, see for instance [15] for a recent survey. We can mainly distinguish ve classes of proposals : (1) languages that combine -calculus and Horn clause logic; (2) languages based on Horn clause logic with equality; (3) languages based on conditional logic; (4) constraint logic programming languages; (5) other languages that try to combine object-oriented, functional and logic paradigms. In this rough classi cation, lpg may be considered as an element of the second class, even if some features like the use of disequations are syntactically allowed. lpg can be considered as an example of a language based on the notion of strong logic programming de ned by Meseguer in [18]. In this framework a program P is a signature together with a nite set of sentences (axioms) in a logic L. The denotational semantics of P is a model MSP of P , which is standard in a well de ned sense. For a program P , the user must be allowed to \test" or \evaluate" its program, i.e. to ask questions about the properties which hold in the model MSP . If a query  is provable in P by the entailment relation of the underlying logic L, then it holds in the standard model by the soundness of L, and the machine must be able to justify the truth of  by giving a set of answers. So, the operational semantics of P is a proof algorithm based on the

entailment relation that allows to prove queries and to give signi cant answers. Because of indeterminism of entailment relation, the implementation must nd out strategies to achieve a relative eciency in the proof, without loosing the \completeness" of the answers. This point is very important and dicult in practice. This is why, we focus on the rules and strategies used to answer queries in the system lpg. The main technical new result of this paper is an extension of \uniform" strategies which is proved to be complete for conditional term rewrite systems. Informally, lpg (for Langage de Programmation Generique)[3, 5] is a generic, logic and functional programming language designed to experiment new concepts in the eld of speci cation, prototyping and high-level programming languages. It is based on concepts of algebraic speci cations, abstract data types and logic programming. Thus, with respect to functional languages, lpg o ers the possibility to de ne predicates or relations. With respect to classical logic programming languages, lpg is generic, i.e. it o ers the possibility to de ne predicates that can be parameterized by other predicates or functions. This feature allows to write \higher-order like" speci cations such as the transitive closure of a relation given as parameter. It is strongly typed and admits user's de nable types and functions. In lpg, functions are de ned by conditional term rewrite systems and predicates are de ned by Horn clauses whose bodies may include \classical" literals, equations or disequations (i.e. negations of equations). The operational semantics of lpg is intended to solve queries (usually called goals) i.e. conjunction of literals, equations or disequations including de ned functions and logical variables. The proof theory for those general goals mixes the SLD-resolution principle with narrowing-based algorithms that are devoted to solve equations and disequations. The paper is organized as follows : Section 2 brie y recalls some general background about algebraic speci cations and rewrite systems. Section 3 gives a short presentation of the language. It outlines the denotational semantics of modules and particularly, of completely instantiated modules which are the \programs" for which the operational semantics is de ned. Section 4 is devoted to the operational semantics of lpg. It presents the main rules of logical entailment that is to say the principle of resolution of literals augmented by an inference system for \solving" equations and disequations. This last system is based on conditional narrowing and uses narrowing-position selection strategies. The completeness of these strategies is investigated and sucient conditions ensuring their completeness are given. At last, we conclude by a short comparison with other languages integrating functional and logic programming and give some insights into the possible future directions to improve the system.

2 Preliminaries In this section, we recall some important notions and notations. See [6, 17] for the missing de nitions about rewriting theory. A many-sorted rst order signature  is a tuple (S; ;  ) where S is a set

of sorts , is an S  -indexed family of operation sets, and  is an S + -indexed family of predicate sets. For every sort s 2 S , every set ss includes the symbols of equality (==) and disequality (=/=). Let X = (Xs js 2 S ) be an S -sorted, countably in nite set of variables . We denote by T (; X )s the set of terms of sort s built from  and X . T (; X ) denotes the set of all terms, i.e., the union [s2S T (; X )s . By Var(t) we denote the set of variables occurring in a term t. A term t is called ground term if Var(t) = ;. A term is called linear if it does not contain multiple occurrences of one variable. An equation (resp. a disequation) is a pair denoted by t==t0 (resp. t=/=t0 ) where t and t0 are terms. A speci cation is a tuple SP = (; E; Cl) where  is a rst order signature, E is a set of conditional equations of the form l==r " to mean that these axioms have to be used as rewrite rules from left to right. The left hand sides of such oriented rules must be innermost terms. Modules of \properties" are designed to de ne rst-order theories which characterize classes of types. For example, in Figure 2, we give two classical theories, namely Equality and Total-Order, that characterize respectively any set supplied with an equivalence relation2 and any set supplied with an ordering. Properties are used to specify generic parameters of generic types or enrichments. The generic parameters are introduced by the keyword \requires". Sorts, operators and predicates of the declaration requires are local declarations in the generic module and the axiomatization of the required property is inherited via the declared renaming. We show in gure 3 a generic module Sorting which requires a data type with total order to de ne the generic sort operator and the generic predicate ordered on sequences. This module uses the generic type of sequences which is available in the prede ned library of lpg and values can be written as [1,2,3] instead of cons(1,cons(2,cons(3,nil))). The notation seq[elem] stands for the sort of the sequences where the sort of elements is elem. In the module Sorting, the equation number 4 contains a conditional expression, like in functional languages. Such an equation is equivalent to the two following conditional rewrite rules : add(x,cons(y,s)) ! cons(x,cons(y,s)) add(x,sort(s)) add(x,nil) ==> [x] add(x,cons(y,s)) ==> x y cons(x,cons(y,s)) cons(y,add(x,s))

if  then else

clauses 1: ordered(s)