Models and equality for logical programming [chapter]

Joseph A. Goguen, José Meseguer
TAPSOFT '87  
We argue that some standard tools from model theory provide a better semantic foundation than the more syntactic and operational approaches usually used in logic programming. In particular, we show how initial models capture the intended semantics of both functional and logic programming, as well as their combination, with existential queries having logical variables (for both functions and relations) in the presence of arbitrary user-defined abstract data types, and with the full power of
more » ... full power of constraint languages, having any desired built-in (computable) relations and functions, including disequality (the negation of the equality relation) as well as the usual ordering relations on the usual built-in types, such as numbers and strings. These results are based on a new completeness theorem for order-sorted Horn clause logic with equality, plus the use of standard interpretations for l~Lxed sorts, functions and relations. Finally, we define "logical programming," based on the concept of institution, and show how it yields a general framework for discussions of this kind. For example, this viewpoint suggests that the natural way to combine functional and logic programming is simply to combine their logics, getting Horn clause logic with equality. existing literature° One reason that [11] may have been obscure to many readers, is the large number of new ideas that it tried to introduce all at once~ here, we attempt to highlight certain ideas by ignoring others. Among the features of Eqlog deliberately downplayed here are: modules~ both hierarchical and generic; theories and views; and "attributes" of operators (e.g., associativity and commutativity}. Although these features greatly increase the expressive power of Eqlog, they would also distract from the basic foundational and semantic issues that we wish to emphasize here. For similar reasons, this paper does not develop most issues concerning the operational semantics of the various systems that are discussed. Thus, unification, term rewriting, narrowing and resolution are only touched upon. They are discussed in somewhat more detail in [11], and will receive full treatment in [23] and [26]. Order-Sorted Logic Ordinary unsorted logic offers the dubious advantage that anything can be applied to anything; for example, 3 * first-na~e(age(false)) < 2 birth-placo(teuperature (329)) is a well-formed expression. Although beloved by hackers of Lisp and Prolog, unsorted logic is too permissive. The trouble is that the usual alternative, many-sorted logic, is too restrictive, since it does not support overloading of function symbols such as_* for integer, rational, and complex numbers. In addition, an expression like does not, strictly speaking, parse (assuming that factorial only applies to natural numbers). Here, we suggest that order-sorted logic, with subsorts and operator loading, plus the additional twist of retracts (although they are not discussed here; see [14] ), really does provide sufficient expressiveness, while still banishing the truly meaningless. Although the specialization of many-sorted logic to many-sorted algebra has been very successfully applied to the theory of abstract data types, many-sorted algebra can produce some very awkward specifications in practice, primarily due to difficulties in handling erroneous expressions, such as dividing by zero in the rationals, or taking the top of an empty stack. In fact there is no really satisfactory way to define either the rationals or stacks with MSA. However, order-sorted algebra overcomes these obstacles through its richer type system, which supports subsorts, overloaded operators, and total functions that would otherwise have to be partial. Moreover, order-sorted algebra is the basis of both OBJ [9] and Eqlog [11]. Finally, order-sorted algebra solves the constructor-selector problem, which, roughly speaking, is to define inverses, called selectors, for constructors; the solution is to restrict selectors to the largest subsorts where they make sense. For example, pop and top are only defined for non-empty stacks. [15] shows not only that order-sorted algebra solves this problem, but also that many-sorted algebra cannot solve it. The essence of order-sorted logic is to provide a subsort partial ordering among the sorts, and to interpret it semantically as subset inclusion, among the carriers of a model, and to support operator overloading that is interpreted as restricting functions to subsorts. Two happy facts are that ordersorted logic is only slightly more difficult than many-sorted logic, and that essentially all results generalize from the many-sorted to the order-sorted case without complication. See [14] for a comprehensive treatment of order-sorted algebra. This paper broadens the logical framework to allow not only algebras, but also models of arbitrary first-order signatures, with both function and predicate symbols, including equality, and gives rules of deduction for Horn clauses in such a logic~ proving their completeness and several other basic results that are directly relevant to our model-theoretic account of logic and functional programming, including initiality and Herbrand theorems. Models Perhaps the origins in proof theory explain the obsession of logic programming theorists with syntactic and proof theoretic constructions. In any case, we believe that more semantic and more abstract tools provide a basis that is both broader and more powerful. In particular, we feel that the usual Herbrand Universe construction is too syntactic and is also unnecessarily restrictive, because: 1. it does not provide for built-in types, such as numbers and infinite trees; 2. it does not provide for user-defined abstract data types; 3. it does not (directly) address the phenomenon of representation independence for terms and for data types, whether built-in or user-defined; and 4. the proofs are more concrete and computational than necessary 2. Of course, these deficiencies can all be patched without great difficulty -for example, [19] shows how to include built-in numbers -but after a few such patches, you have something enough like the initial model approach that you might as well, or better, take advantage of the powerful machinery associated with that tradition. The reasgn for being interested in models is just that a standard model can provide the implementer with a clear standard for correctness, and can also provide the programmer and user with a clear model for what to expect when programs are actually run.
doi:10.1007/bfb0014969 dblp:conf/tapsoft/GoguenM87 fatcat:tc24f3f4vzgirdjpouvaytwjnq