450 research outputs found

    Logic programming in the context of multiparadigm programming: the Oz experience

    Full text link
    Oz is a multiparadigm language that supports logic programming as one of its major paradigms. A multiparadigm language is designed to support different programming paradigms (logic, functional, constraint, object-oriented, sequential, concurrent, etc.) with equal ease. This article has two goals: to give a tutorial of logic programming in Oz and to show how logic programming fits naturally into the wider context of multiparadigm programming. Our experience shows that there are two classes of problems, which we call algorithmic and search problems, for which logic programming can help formulate practical solutions. Algorithmic problems have known efficient algorithms. Search problems do not have known efficient algorithms but can be solved with search. The Oz support for logic programming targets these two problem classes specifically, using the concepts needed for each. This is in contrast to the Prolog approach, which targets both classes with one set of concepts, which results in less than optimal support for each class. To explain the essential difference between algorithmic and search programs, we define the Oz execution model. This model subsumes both concurrent logic programming (committed-choice-style) and search-based logic programming (Prolog-style). Instead of Horn clause syntax, Oz has a simple, fully compositional, higher-order syntax that accommodates the abilities of the language. We conclude with lessons learned from this work, a brief history of Oz, and many entry points into the Oz literature.Comment: 48 pages, to appear in the journal "Theory and Practice of Logic Programming

    A requirements specification for a software design support system

    Get PDF
    Most existing software design systems (SDSS) support the use of only a single design methodology. A good SDSS should support a wide variety of design methods and languages including structured design, object-oriented design, and finite state machines. It might seem that a multiparadigm SDSS would be expensive in both time and money to construct. However, it is proposed that instead an extensible SDSS that directly implements only minimal database and graphical facilities be constructed. In particular, it should not directly implement tools to faciliate language definition and analysis. It is believed that such a system could be rapidly developed and put into limited production use, with the experience gained used to refine and evolve the systems over time

    Why Ciao? An overview of the ciao system's design philosophy

    Get PDF
    Our intention in this note is not to provide a listing of the many features of the Ciao system: this can be found in part for example in the brochures announcing upcoming versions, in the Ciao website, or in more feature-oriented descriptions such as. Instead in this document we would like to describe the objectives and reasoning followed in our design as well as the fundamental characteristics that in our opinion make Ciao quite unique and hopefully really useful to you as a Ciao user

    Bridging the Gap between Object-oriented and Logic Programming

    Get PDF
    A description is given of an interface that was developed between Loops and Xerox Quintus Prolog. Loops is an extension to the Xerox AI environment to support object-oriented programming; Xerox Quintus Prolog is a version of Prolog that runs on Xerox Lisp machines. Such a bridge enables all the support tools of both environments to be accessed, and degradation of performance that occurs when one language is implemented top of another is avoided. The interface has three layers. At the lowest level, a set of Prolog predicates gives the Prolog programmer access to Loops objects. This lowest level is the bridge from Prolog to Loops. At the next level, programming tools in the Loops environment let object methods be defined in Prolog. At the highest level, the Prolog programmer can treat Prolog clauses as Loops objects that can be manipulated outside the Prolog database. Each layer can be used independently

    INCONSISTENCY HANDLING IN MULTIPERSPECTIVE SPECIFICATIONS

    No full text
    Published versio

    Proceedings of the Resolve Workshop 2006

    Get PDF
    The aim of the RESOLVE Workshop 2006 was to bring together researchers and educators interested in: Refining formal approaches to software engineering, especially component-based systems, and introducing them into the classroom. The workshop served as a forum for participants to present and discuss recent advances, trends, and concerns in these areas, as well as formulate a common understanding of emerging research issues and possible solution paths
    corecore