DOCSLIB.ORG

A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java LogicObjects : A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java Sergio Castro Kim Mens Paulo Moura RELEASeD lab RELEASeD lab Dept. of Computer Science ICTEAM Institute ICTEAM Institute University of Beira Interior Université catholique de Université catholique de & CRACS, INESC–TEC Louvain, Belgium Louvain, Belgium Portugal [email protected] [email protected] [email protected] ABSTRACT Although there exists some other work that focusses on Logic programming is well suited for declaratively solving facilitating the interaction from an object-oriented language computational problems that require knowledge representa- to a logic language, to the best of our knowledge this is the tion and reasoning. Object-oriented languages, on the other first approach that provides a truly transparent, automatic hand, are well suited for modeling real-world concepts and and customizable integration from the perspective of the profit from rich ecosystems developed around them, which object-oriented language. are often missing from logic languages. For applications that This paper is structured as follows: Section 2 presents a require both the declarative power of logic programming and problem of declarative nature and its implementation in a the rich modeling expressiveness and development environ- logic language. This will be referenced in the next sections. ments offered by object-oriented languages, there is a need Section 3 presents our framework and shows how it enables for reconciling both worlds. LogicObjects is our linguistic a transparent access from Java to our implementation in symbiosis framework for integrating Prolog within the Java logic. Section 4 discuss relevant related work and section 5 language. It extends Java with annotations that allow Java presents our conclusions and future work. programs to interact transparently and automatically with Prolog programs. 2. CASE STUDY: THE LONDON UNDERGROUND This case addresses a typical problem that can be imple- Keywords mented easily with a logic programming language: a query- ing system about subway lines and stations in a big city Linguistic Symbiosis, Object-Oriented Programming, Logic (e.g., to query the number of intermediate stations from Programming, Multi-paradigm programming one station to another). Since most public transport sys- tems require a user-friendly interface, which can be devel- 1. INTRODUCTION oped more easily with an object-oriented language, a good Object-oriented programming languages have demonstra- solution would be to implement the declarative part of the ted their usefulness for modeling real-world concepts. In application in Prolog and the user interface in Java. addition, the availability of continuously growing software The first stage of the problem consists in expressing our ecosystems around them, including advanced IDEs and ex- knowledge about the London Underground in terms of logic tensive libraries, has contributed to their success. Declara- statements. Most of the code in this section has been taken tive languages like Prolog, however, are more convenient for \as is" from [7]. However, we did introduce an interesting expressing problems of declarative nature, such as rule-based variation in the original code. Instead of implementing it systems [6, 15]. in plain Prolog, we used Logtalk [12], a portable object- Linguistic symbiosis [11] has been used in the past to solve oriented layer on top of Prolog, thus allowing us to benefit the problem of integrating programs written in different lan- from the symbiosis features it offers while at the same time guages. In particular, the SOUL [9] language implements ad- facilitating the mapping that needs to be made between ob- vanced language symbiosis features between Smalltalk and jects belonging to the two worlds. Prolog [6, 10]. Some limits and issues with SOUL have been In our universe of discourse, stations are connected to discussed in [9]. This work is a first step towards a frame- other stations through underground lines. A station is nearby work that overcomes most of these limitations. another one if there is at most one station in between them. Finally, a station A is reachable from another station B if there exists a list of stations L that form a path going from B to A. Permission to make digital or hard copies of all or part of this work for Listing 1 shows the Logtalk definition of the metro object personal or classroom use is granted without fee provided that copies are (we omitted some predicate clauses to save space). Note not made or distributed for profit or commercial advantage and that copies that, although Logtalk also supports classes, we are not us- bear this notice and the full citation on the first page. To copy otherwise, to ing the word class here, since we are just defining a prototype republish, to post on servers or to redistribute to lists, requires prior specific object and to avoid confusion with Java classes. The metro permission and/or a fee. RAM-SE’12, June 13, 2012, Beijing, China object encapsulates the knowledge about how stations are Copyright 2012 ACM 978-1-4503-1277-6/12/06 ...$10.00. connected (lines 5{8), plus the rules for the logic predicates nearby/2 (lines 10{11) and reachable/3 (lines 13{14). The messages (queries) that the metro object can answer are specified using the public/1 directive (line 2). 1 :− object ( metro ) . 2 3: − public ([connected/3, nearby/2, reachable/3]). 4 5 connected(station(bond s t r e e t ) , station(oxford circus),line(central)). 6 connected(station(oxford c i r c u s ) , station(tottenham c o u r t road),line(central)). 7 connected(station(bond s t r e e t ) , station(green park),line(jubilee)). 8... 9 10 nearby(X,Y):− connected(X,Y,L) . 11 nearby(X,Y):− connected(X,Z,L) ,connected(Z,Y,L) . 12 Figure 1: Objects from two different worlds living 13 reachable(X,Y,[]):− connected(X,Y,L) . 14 reachable(X,Y,[Z jR]):− connected(X,Z,L) ,reachable(Z,Y,R) . in symbiosis. 15 16 :− end object . 11) answers if the station is nearby another station received Listing 1: The metro object in Logtalk as a parameter. The method reachable/1 (line 13) answers Messages are sent in Logtalk using the ::/2 operator. For if the station received as parameter is reachable from the example, to find which stations are connected to the station receiver station object (or answers the reachable stations if Bond Street we can use the query shown in listing 2. the parameter is an unbound variable). The method reach- able/2 (line 15) does the same, but includes in its second metro :: connected(station(bond street), Station , Line). argument a list with all the intermediate stations. All these methods are delegated to the metro object. Listing 2: Invoking a Logtalk method 1 :− object ( s t a t i o n ( Name ) ) . 2 Logtalk and Prolog both support non-deterministic queries, 3: − public ([name/1, connected/1, connected/2, nearby/1, reachable/1, reachable/2]). which allows retrieving all existing solutions for a query us- 4 5 name(Name) :− parameter(1, Name). ing backtracking, and meta-programming, which allows e.g. 6 to construct a list with all solutions to a query. For exam- 7 connected(Station) :− connected(Station , ). 8 ple, to get a list of all stations connected to Bond Street we 9 connected(Station, L) :− self(Self), metro :: connected(Self , Station , L). could write the query shown in listing 3. 10 11 nearby(Station) :− self(Self), metro :: nearby(Self , f i n d a l l ( S t a t i o n ) . S t a t i o n , 12 metro :: connected(station(bond street), Station , Line), 13 reachable(Station) :− reachable(Station , ). S t a t i o n s 14 ). 15 reachable(Station , IntermediateStations) :− self(Self), metro :: reachable(Self , Station , IntermediateStations). 16 Listing 3: Invoking a Logtalk method using the 17 :− end object . findall/3 meta-predicate Listing 5: The station object in Logtalk Listing 4 shows the definition of a parametric object [13] line/1. Finally, we show the loader file of our library. A loader file 1 :− object ( l i n e ( Name ) ) . defines the collection of objects that should be loaded (line 2 2) when requiring a Logtalk library. We further discuss these 3: − public ([name/1, connects/2]) . 4 objects in the next section. 5 name(Name) :− parameter(1, Name). 6 7 connects(Station1, Station2) :− self(Self), 1 :− initialization ( metro :: connected(Station1 , Station2 , Self). 2 logtalk load([metro, station , line]) 8 3). 9 :− end object . Listing 6: The load all.lgt loader file Listing 4: The line object in Logtalk The object's sole parameter (line 1) can be retrieved with the method name/1 (line 5). This object also defines a con- 3. LOGICOBJECTS nects/2 method (line 7) that answers stations directly con- In the previous section we have shown the implementa- nected by the line represented by the receiver object. This tion of the declarative part of our case study using Logtalk method implementation is delegated to the metro object. objects. In this section, we add Java counterparts to these Our last object is the station object (Listing 5). As for objects and show how objects from the Java world can sym- the line object, it is also a parametric object having as sole biotically interact with objects in Logtalk. All these objects parameter the name of a station (line 1). It defines a method are illustrated in figure 1. connected/1 (line 7) that answers if the station is connected In the remainder of this section we describe the linguistic with another station (or answers the stations that are con- symbiosis techniques employed by our LogicObjects frame- nected if the parameter is an unbound variable).
Load more

Recommended publications
  • From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse
    From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse Paulo Moura Dep. of Computer Science, Univ. of Beira Interior, Portugal Center for Research in Advanced Computing Systems INESC Porto, Portugal http://logtalk.org/ [email protected] ICLP 2009 Inivited Talk Someone said I need one... 2 Spoilers • Objects in a Prolog world • Logtalk design goals • Logtalk architecture • Logtalk versus Prolog and Prolog modules • Logtalk overview and quick tour • Some demos (if time allows) • Logtalk as a portable Prolog application • Logtalk programming support 3 A warning... • I have a laser and I’m not afraid to use it ... Beware of asking embarrassing questions! • But please feel free to interrupt and ask nice ones that make the speaker shine! 4 A bit of history... • Project started in January 1998 • First version for registered users in July 1998 • First public beta in October 1998 • First stable version in February 1999 5 Logtalk in numbers • Compiler + runtime: ~11000 lines of Prolog code • 37 major releases, 122 including minor ones • Current version: Logtalk 2.37.2 minor release number major release number second generation of Logtalk • ~1500 downloads/month (so many earthlings, so little time) 6 Logtalk distribution • Full sources (compiler/runtime, Prolog config files, libraries) • MacOS X (pkg), Linux (rpm), Debian (deb), and Windows (exe) installers XHTML and PDF User and Reference Manuals • (121 + 144 pages) • +90 programming examples • Support for several text editors and syntax highlighters (text services and code publishing) 7 Objects in Prolog?!? We’re being invaded! 8 Objects have identifiers and dynamic state! • It seems Prolog modules are there first: Identifier! :- module(broadcast, [...]).
    [Show full text]
  • On the Implementation of a Cloud-Based Computing Test Bench Environment for Prolog Systems †
    information Article On the Implementation of a Cloud-Based Computing Test Bench Environment for Prolog Systems † Ricardo Gonçalves, Miguel Areias * ID and Ricardo Rocha ID CRACS & INESC TEC and Faculty of Sciences, University of Porto, Rua do Campo Alegre, 1021/1055, 4169-007 Porto, Portugal; [email protected] (R.G.); [email protected] (R.R.) * Correspondence: [email protected] † This paper is an extended version of our paper published in the Symposium on Languages, Applications and Technologies 2017. Received: 13 September 2017; Accepted: 13 October 2017; Published: 19 October 2017 Abstract: Software testing and benchmarking are key components of the software development process. Nowadays, a good practice in large software projects is the continuous integration (CI) software development technique. The key idea of CI is to let developers integrate their work as they produce it, instead of performing the integration at the end of each software module. In this paper, we extend a previous work on a benchmark suite for the YAP Prolog system, and we propose a fully automated test bench environment for Prolog systems, named Yet Another Prolog Test Bench Environment (YAPTBE), aimed to assist developers in the development and CI of Prolog systems. YAPTBE is based on a cloud computing architecture and relies on the Jenkins framework as well as a new Jenkins plugin to manage the underlying infrastructure. We present the key design and implementation aspects of YAPTBE and show its most important features, such as its graphical user interface (GUI) and the automated process that builds and runs Prolog systems and benchmarks.
    [Show full text]
  • Comparative Programming Languages CM20253
    We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist And there are many more factors we could talk about in making choices of language The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design The End There are many languages out there, both general purpose and specialist We have briefly covered many aspects of language design And there are many more factors we could talk about in making choices of language Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages And then the interopability of languages becomes important For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project For example, can you easily join together code written in Java and C? The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important The End Or languages Often a single project can use several languages, each suited to its part of the project And then the interopability of languages becomes important For example, can you easily
    [Show full text]
  • A Simple Approach to Distributed Objects in Prolog
    A Simple Approach to Distributed Objects in Prolog Manuel Carro Manuel Hermenegildo Computer Science School Technical University of Madrid Boadilla del Monte, E-28660,Spain {mcarro,herme}@fi.upm.es Abstract. We present the design of a distributed object system for Prolog, based on adding remote execution and distribution capabilities to a previously existing object system. Remote execution brings RPC into a Prolog system, and its semantics is easy to express in terms of well-known Prolog builtins. The final distributed object design features state mobility and user-transparent network behavior. We sketch an implementation which provides distributed garbage collection and some degree of tolerance to network failures. We provide a preliminary study of the overhead of the communication mechanism for some test cases. Keywords: Objects, Distributed Execution, Remote Calis, Migration, Garbage Collection. 1 Introduction Distributed objects are the natural sequel to object oriented programming and distributed programming. They can be used to implement a wide range of software systems: remote databases, service migration to improve access speed, automatic caching, implementation of stateful agents, etc. A good deal of proposals combining distribution and objects have been developed in the realm of procedural and 00 languages; however, many of them boil down to adding convenient librarles to an existing host language which did not have any provisión for distributed execution [BGL98]. Among the proposals which address 00 and distribution from scratch we may cite Emerald [Jul88], Obliq [Car95], and, to some extent, Jini [We + OO]. Although there have been several proposals for coupling LP and 00 in the logic programming arena (e.g., SICStus objects [Swe99], Prolog++ [Mos94], LogTalk [MouOO], O'Ciao [PB02], and others), few proposal have been made, to the best of our knowledge, to couple objects and distribution.
    [Show full text]
  • 11 – Logic Paradigm and Prolog
    11 – Logic Paradigm and Prolog Logic: Programs are built by defining logical rules and goals. The runtime environment tries to achieve the goals by logically deduction. Examples: Prolog, ASP, Datalog, Florid, Logtalk There are other paradigms as well. This section focuses on the logic paradigm, sometimes called “declarative” programming. In this paradigm, programs are built by defining logical rules and goals, and the runtime environment tries to achieve the goals by logical deduction. By far the most common logic programming language is Prolog, although there are others (ASP, Datalog, Florid, Logtalk, for example). There are also many languages and systems that are derived from Prolog, such as the CLIPS expert system shell we use in CSc-180. You are probably already familiar with Boolean logic. In Boolean logic, names are given to things that are either TRUE or FALSE. The operations AND, OR, and NOT then allow us to build a rich set of rules of inference, such as DeMorgan’s rule, and Modus Ponens. Boolean logic is sufficiently powerful for building the digital circuitry used in a CPU. As a programming tool, however, Boolean logic has serious limitations. The only values available are TRUE and FALSE, which becomes problematic if we want to use other values, such as numbers or strings. It also is difficult in Boolean logic to express logical rules that can be applied generally depending on values that aren’t TRUE and FALSE. For example, if we want to create a rule that expresses that a person is eligible for social security if their age is over 62, it is difficult because there is no mechanism in Boolean logic for associating a number (such as age) with a person.
    [Show full text]
  • A Proposal of Hybrid Knowledge Engineering and Refinement
    A Proposal of Hybrid Knowledge Engineering and Refinement Approach Grzegorz J. Nalepa and Igor Wojnicki Institute of Automatics, AGH – University of Science and Technology, Al. Mickiewicza 30, 30-059 Kraków, Poland [email protected] [email protected] Abstract on several observations related to the Software and Knowl- edge Engineering concepts described below. The paper deals with some possible applications of Knowl- This paper presents a concept of a new software engineer- edge Engineering methods to the practical Software Engi- neering. Such an integration could provide a way to over- ing approach based on knowledge engineering methods. In come some constant problems present in the contemporary the paper some important features of both KE and SE ap- Software Engineering. This paper describes foundations of proaches are summarized. Furthermore, common design the HEKATE Project, which aims at incorporating well es- and evaluation problems encountered in SE are outlined. tablished Knowledge Engineering tools and paradigms into Most of these problems can be successfully approached, the Software Engineering domain. A new Hybrid Knowledge and possibly minimized in the field of KE and RBS design. Engineering (HEKATE) methodology is proposed, which This is why, selected concepts and tools developed for the would allow for faster development of highly reliable soft- MIRELLA Project are presented; they aim at supporting the ware. The HEKATE design process is introduced which of- design and evaluation of RBS. Finally, the main concept of fers important capabilities of formal verification, and gradual the hybrid knowledge engineering, on which the HEKATE refinement of software from the conceptual model stage to an executable prototype.
    [Show full text]
  • Enabling Logic Programming in Java Through Linguistic Symbiosis ?
    LogicObjects: Enabling Logic Programming in Java Through Linguistic Symbiosis ? Sergio Castro1, Kim Mens1, and Paulo Moura2 1 ICTEAM Institute, Université catholique de Louvain, Belgium {sergio.castro,kim.mens}@uclouvain.be 2 Center for Research in Advanced Computing Systems, INESC–TEC, Portugal [email protected] Abstract. While object-oriented programming languages are good at modelling real-world concepts and benefit from rich libraries and devel- oper tools, logic programming languages are well suited for declaratively solving computational problems that require knowledge reasoning. Non- trivial declarative applications could take advantage of the modelling fea- tures of object-oriented programming and of the rich software ecosystems surrounding them. Linguistic symbiosis is a common approach to enable complementary use of languages of different paradigms. However, the problem of concepts leaking from one paradigm to another often hinders the applicability of such approaches. This issue has mainly been reported for object-oriented languages participating in a symbiotic relation with a logic language. To address this issue, we present LogicObjects, a lin- guistic symbiosis framework for transparently and (semi-) automatically enabling logic programming in Java, that aims to solve most of the prob- lems of paradigm leaking reported in other works. Keywords: Linguistic Symbiosis, Object-Oriented Programming, Logic Programming, Multi-Paradigm Programming 1 Introduction Object-oriented languages like Java have demonstrated their usefulness for mod- elling real-world concepts. In addition, the availability of continuously growing software ecosystems around them, including advanced IDEs and extensive li- braries, has contributed to their success. Declarative languages like Prolog are more convenient for expressing problems of declarative nature, such as expert systems [6,16].
    [Show full text]
  • A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java
    LogicObjects : A Linguistic Symbiosis Approach to Bring the Declarative Power of Prolog to Java Sergio Castro Kim Mens Paulo Moura RELEASeD lab RELEASeD lab Dept. of Computer Science ICTEAM Institute ICTEAM Institute University of Beira Interior Université catholique de Université catholique de & CRACS, INESC–TEC Louvain, Belgium Louvain, Belgium Portugal [email protected] [email protected] [email protected] ABSTRACT Although there exists some other work that focusses on Logic programming is well suited for declaratively solving facilitating the interaction from an object-oriented language computational problems that require knowledge representa- to a logic language, to the best of our knowledge this is the tion and reasoning. Object-oriented languages, on the other first approach that provides a truly transparent, automatic hand, are well suited for modeling real-world concepts and and customizable integration from the perspective of the profit from rich ecosystems developed around them, which object-oriented language. are often missing from logic languages. For applications that This paper is structured as follows: Section 2 presents a require both the declarative power of logic programming and problem of declarative nature and its implementation in a the rich modeling expressiveness and development environ- logic language. This will be referenced in the next sections. ments offered by object-oriented languages, there is a need Section 3 presents our framework and shows how it enables for reconciling both worlds. LogicObjects is our linguistic a transparent access from Java to our implementation in symbiosis framework for integrating Prolog within the Java logic. Section 4 discuss relevant related work and section 5 language.
    [Show full text]
  • The Logtalk Handbook Release V3.39.0
    The Logtalk Handbook Release v3.39.0 Paulo Moura Jun 17, 2020 CONTENTS: 1 User Manual 1 1.1 Declarative object-oriented programming.............................1 1.2 Main features.............................................2 1.2.1 Integration of logic and object-oriented programming..................2 1.2.2 Integration of event-driven and object-oriented programming.............2 1.2.3 Support for component-based programming.......................3 1.2.4 Support for both prototype and class-based systems...................3 1.2.5 Support for multiple object hierarchies..........................3 1.2.6 Separation between interface and implementation....................3 1.2.7 Private, protected and public inheritance.........................3 1.2.8 Private, protected and public object predicates......................4 1.2.9 Parametric objects.....................................4 1.2.10 High level multi-threading programming support....................4 1.2.11 Smooth learning curve...................................4 1.2.12 Compatibility with most Prolog systems and the ISO standard.............4 1.2.13 Performance.........................................4 1.2.14 Logtalk scope........................................5 1.3 Nomenclature............................................5 1.3.1 Smalltalk nomenclature..................................6 1.3.2 C++ nomenclature.....................................7 1.3.3 Java nomenclature.....................................8 1.3.4 Python nomenclature....................................9 1.4 Messages..............................................
    [Show full text]
  • From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse
    From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse Paulo Moura Dep. of Computer Science, Univ. of Beira Interior, Portugal Center for Research in Advanced Computing Systems INESC Porto, Portugal http://logtalk.org/ [email protected] 2011 Talk @ Uni Bonn Lecture „Advanced Logic Programming“ Chapter 8: Logtalk -- Objects in Prolog R O O T S Objects in Prolog?!? 2 Objects have identifiers and dynamic state! It seems Prolog modules were there first: Identifier! :- module(broadcast, [...]). Dynamic state! :- dynamic(listener/4). ... assert_listener(Templ, Listener, Module, TheGoal) :- asserta(listener(Templ, Listener, Module, TheGoal)). retract_listener(Templ, Listener, Module, TheGoal) :- retractall(listener(Templ, Listener, Module, TheGoal)). © 2011 Paulo Moura Advanced Logic Programming, Chapter 7. „Logtalk --Objects in Prolog“ Page 8-3 R O O T S Objects inherit lots of stuff I don’t need! Objects are not necessarily tied to hierarchies. But how about typical Prolog module code? Just import everything from :- module(aggregate, [...]). each module! :- use_module(library(ordsets)). :- use_module(library(pairs)). :- use_module(library(error)). :- use_module(library(lists)). :- use_module(library(apply)).... © 2011 Paulo Moura Advanced Logic Programming, Chapter 7. „Logtalk --Objects in Prolog“ Page 8-4 R O O T S Objects are dynamically created! Only if really necessary. Objects can be (and often are) static, simply loaded from source files... But, guess what, Prolog modules were there first: Dynamically creates module foo if it doesn’t exist! ?- foo:assertz(bar). yes © 2011 Paulo Moura Advanced Logic Programming, Chapter 7. „Logtalk --Objects in Prolog“ Page 8-5 R O O T S Why not stick to modules?!? Prolog modules fail to: enforce encapsulation in most implementations, you can call any module predicate using explicit qualification implement predicate namespaces due to the import semantics and current practice, module predicate names are often prefixed..
    [Show full text]
  • From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse
    From Plain Prolog to Logtalk Objects: Effective Code Encapsulation and Reuse Paulo Moura Dep. of Computer Science, Univ. of Beira Interior, Portugal Center for Research in Advanced Computing Systems INESC Porto, Portugal http://logtalk.org/ [email protected] 2011 Talk @ Uni Bonn Lecture „Advanced Logic Programming“ Chapter 9b: Logtalk -- Objects in Prolog Logtalk – Objects in Prolog Modules as Objects??? 2 Objects are dynamically created! Module = Object? Modules are typically static, simply loaded from source files... But access to a non-existing module implicitly creates it at run-time: ?- p(X), X:assertz(something). yes Dynamically creates module if it doesn’t exist! © 2011 Paulo Moura Advanced Logic Programming, Chapter 9. „Logtalk --Objects in Prolog“ Page 9-3 Objects have identifiers and dynamic state! Module = Object? Identifier! :- module(broadcast, [...]). Dynamic state! :- dynamic(listener/4). ... assert_listener(Templ, Listener, Module, TheGoal) :- asserta(listener(Templ, Listener, Module, TheGoal)). retract_listener(Templ, Listener, Module, TheGoal) :- retractall(listener(Templ, Listener, Module, TheGoal)). © 2011 Paulo Moura Advanced Logic Programming, Chapter 9. „Logtalk --Objects in Prolog“ Page 9-4 Objects can inherit Module import = Inheriatance? :- module(aggregate, [...]). :- use_module(library(ordsets)). :- use_module(library(pairs)). :- use_module(library(error)). :- use_module(library(lists)). :- use_module(library(apply)).... © 2011 Paulo Moura Advanced Logic Programming, Chapter 9. „Logtalk --Objects in Prolog“
    [Show full text]
  • Local Copy of the SWI Prolog Manual, Version 7.2.3 (August 2015)
    VU University Amsterdam University of Amsterdam De Boelelaan 1081a, 1081 HV Amsterdam Kruislaan 419, 1098 VA Amsterdam The Netherlands The Netherlands ˜ Reference Manual Updated for version 7.2.3, August 2015 Jan Wielemaker [email protected] http://www.swi-prolog.org SWI-Prolog is a comprehensive and portable implementation of the Prolog programming language. SWI-Prolog aims to be a robust and scalable implementation supporting a wide range of applications. In particular, it ships with a wide range of interface libraries, providing interfaces to other languages, databases, graphics and networking. It provides extensive support for managing HTML/SGML/XML and RDF documents. The system is particularly suited for server applications due to robust support for multithreading and HTTP server libraries. SWI-Prolog is designed in the ‘Edinburgh tradition’. In addition to the ISO Prolog stan- dard it is largely compatible to Quintus, SICStus and YAP Prolog. SWI-Prolog provides a compatibility framework developed in cooperation with YAP and instantiated for YAP, SICStus and IF/Prolog. SWI-Prolog aims at providing a good development environment, including extensive ed- itor support, graphical source-level debugger, autoloading and ‘make’ facility and much more. SWI-Prolog editor and the PDT plugin for Eclipse provide alternative environ- ments. This document gives an overview of the features, system limits and built-in predicates. ˜ This work is licensed under the Creative Commons Attribution- ShareAlike 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by-sa/3.0/ or send a let- ter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.
    [Show full text]