The XSB System Version 3.3.X Volume 1: Programmer's Manual

Total Page:16

File Type:pdf, Size:1020Kb

The XSB System Version 3.3.X Volume 1: Programmer's Manual The XSB System Version 3.3.x Volume 1: Programmer’s Manual xsb Terrance Swift David S. Warren Konstantinos Sagonas Juliana Freire Prasad Rao Baoqiu Cui Ernie Johnson Luis de Castro Rui F. Marques Diptikalyan Saha Steve Dawson Michael Kifer July 4, 2013 Credits Day-to-day care and feeding of XSB including bug fixes, ports, and configuration management is currently done by David Warren and Terrance Swift with the help of Michael Kifer. In the past Kostis Sagonas, Prasad Rao, Steve Dawson, Juliana Freire, Ernie Johnson, Baoqiu Cui, Bart Demoen and Luis F. Castro have provided tremendous help. In Version 3.3, the core engine development of the SLG-WAM has been mainly implemented by Terrance Swift, Kostis Sagonas, Prasad Rao, Juliana Freire, Ernie Johnson, Luis Castro and Rui Marques. The breakdown, very roughly, was that Terrance Swift wrote the initial tabling engine, the SLG-WAM, and its built-ins; and leads the current development of the tabling subsystem. Prasad Rao reimplemented the engine’s tabling subsystem to use tries for variant-based table access and Ernie Johnson extended and refactored these routines in a num- ber of ways, including adding call subsumption. Kostis Sagonas implemented most of tabled negation. Juliana Freire revised the table scheduling mechanism starting from Version 1.5.0 to create the batched and local scheduling that is cur- rently used. Baoqiu Cui revised the data structures used to maintain delay lists, and added attributed variables to the engine. Luis Castro rewrote the emulator to use jump tables and wrote a heap-garbage collector for the SLG-WAM. Rui Marques was responsible for the concurrency control algorithms used for shared tables, and mainly responsible for making the XSB engine multi-threaded. The incremental table maintenance subsystem was designed and implemented by Diptikalyan Saha. Other engine work includes the following. Memory expansion code for WAM stacks was written by Ernie Johnson, Bart Demoen and David S. Warren. Heap garbage collection was written by Luis de Castro, Kostis Sagonas and Bart Demoen. Atom space garbage collection was written by David Warren; table garbage collection was written by Terrance Swift based in part on space recla- mation code written by Prasad Rao. Rui Marques rewrote much of the engine to make it compliant with 64-bit architectures. Assert and retract code was based on code written by Jiyang Xu; it significantly revised by David S. Warren, who added alternative, multiple, and star indexing and by Terrance Swift who im- plemented dynamic clause garbage collection. Trie assert/retract code, and trie interning code was written by Prasad Rao, as was most code for reclaiming table space. The current version of findall/3 was re-written from scratch by Bart Demoen, as was XSB’s throw and catch mechanism. 64-bit floats were added by Charles Rojo. Walter Wilson has written several of XSB’s builtin predicates. In terms of core system Prolog code, Kostis Sagonas was responsible for HiLog compilation and associated built-ins as well as coding or revising many standard predicates. Steve Dawson implemented Unification Factoring. The revision of 2 XSB’s I/O into ISO-compatible streams was done by Michael Kifer and Terrance Swift. The auto_table and suppl_table directives were written by Kostis Sagonas. The DCG expansion module was written by Kostis Sagonas for non- tabled code and by Baoqiu Cui, Terrance Swift and David Warren for tabled code. The handling of the multifile directive was written by Baoqiu Cui. C.R. Ramakrishnan wrote the mode analyzer for XSB. Michael Kifer implemented the storage module. The multi-threaded API was written by Terrance Swift and Rui Marques. Michael Kifer has been in charge of XSB’s installation procedures, rewriting parts of the XSB code to make XSB configurable with GNU’s Autoconf, im- plementing XSB’s package system, and integrated GPP with XSB’s compiler. GPP, the source code preprocessor used by XSB, was written by Denis Auroux, who also wrote the GPP manual reproduced in Appendix A. The starting point of XSB (in 1990) was PSB-Prolog 2.0 by Jiyang Xu. PSB- Prolog in its turn was based on SB-Prolog, primarily designed and written by Saumya Debray, David S. Warren, and Jiyang Xu. Thanks are also due to Weidong Chen for his work on Prolog clause indexing for SB-Prolog, to Richard O’Keefe, who contributed the Prolog code for the Prolog reader and the C code for the tokenizer, and to Ciao Prolog whose write_term/[2,3] we use. ... Now what did I forget this time ? Contents 1 Introduction 1 1.1 Using This Manual ................................ 6 2 Getting Started with XSB 7 2.1 Installing XSB under UNIX ........................... 7 2.1.1 Possible Installation Problems ...................... 11 2.2 Installing XSB under Windows ......................... 12 2.2.1 Using Cygnus Software’s CygWin32 .................. 12 2.2.2 Using Microsoft Visual C++ ...................... 12 2.3 Invoking XSB ................................... 15 2.4 Compiling XSB programs ............................ 16 2.5 Sample XSB Programs .............................. 16 2.6 Exiting XSB ................................... 17 3 System Description 18 3.1 Entering and Exiting XSB from the Command Line ............. 18 3.2 The System and its Directories ......................... 19 3.3 How XSB Finds Files: Source File Designators ................ 20 3.4 The Module System of XSB ........................... 21 3.5 Standard Predicates in XSB ........................... 28 3.6 The Dynamic Loader and its Search Path ................... 28 3.6.1 Changing the Default Search Path and the Packaging System . 28 3.6.2 Dynamically loading predicates in the interpreter ........... 31 i CONTENTS ii 3.7 Command Line Arguments ........................... 31 3.8 Memory Management .............................. 36 3.9 Compiling, Consulting, and Loading ...................... 37 3.9.1 Static Code ................................ 37 3.9.2 Dynamic Code .............................. 39 3.9.3 The multifile directive .......................... 39 3.10 The Compiler ................................... 40 3.10.1 Invoking the Compiler .......................... 40 3.10.2 Compiler Options ............................ 42 3.10.3 Specialization ............................... 48 3.10.4 Compiler Directives ........................... 50 3.10.5 Inline Predicates ............................. 56 3.11 A Note on ISO Compatibility .......................... 57 4 Syntax 59 4.1 Terms ....................................... 59 4.1.1 Integers .................................. 59 4.1.2 Floating-point Numbers ......................... 60 4.1.3 Atoms ................................... 60 4.1.4 Variables ................................. 61 4.1.5 Compound Terms ............................ 61 4.1.6 Lists .................................... 63 4.2 From HiLog to Prolog .............................. 64 4.3 Operators ..................................... 66 5 Using Tabling in XSB: A Tutorial Introduction 70 5.1 Tabling in the Context of a Prolog System ................... 70 5.2 Definite Programs ................................ 71 5.2.1 Call Variance vs. Call Subsumption .................. 75 5.2.2 Table Scheduling Strategies ....................... 77 5.2.3 Interaction Between Prolog Constructs and Tabling ......... 79 CONTENTS iii 5.2.4 Potential Pitfalls in Tabling ....................... 82 5.3 Normal Programs ................................. 84 5.3.1 Stratified Normal Programs ....................... 84 5.3.2 Non-stratified Programs ......................... 87 5.3.3 On Beyond Zebra: Implementing Other Semantics for Non-stratified Programs 91 5.4 Answer Subsumption ............................... 93 5.4.1 Types of Answer Subsumption ..................... 93 5.4.2 Examples of Answer Subsumption ................... 95 5.4.3 Term-Sets ................................. 98 5.5 Tabling for Termination ............................. 101 5.5.1 Subgoal Abstraction ........................... 102 5.5.2 Bounded Rationality through Radial Restraint ............ 104 5.6 Incremental Table Maintenance ......................... 106 5.6.1 Examples ................................. 106 5.6.2 Incremental Tabling using Interned Tries ............... 111 5.6.3 View Consistency ............................. 112 5.6.4 Summary and Implementation Status ................. 113 5.6.5 Predicates for Incremental Table Maintenance ............. 113 5.7 Compatability of Tabling Modes and Predicate Attributes .......... 119 6 Standard and General Predicates 122 6.1 Input and Output ................................ 122 6.1.1 I/O Stream Implementation ....................... 123 6.1.2 ISO Streams ............................... 124 6.1.3 DEC-IO Style File Handling ....................... 131 6.1.4 Character I/O .............................. 133 6.1.5 Term I/O ................................. 137 6.1.6 Special I/O ................................ 145 6.2 Interactions with the Operating System .................... 151 6.2.1 The path_sysop/2 interface ....................... 153 CONTENTS iv 6.3 Evaluating Arithmetic Expressions through is/2 ............... 155 6.3.1 Evaluable Functors for Arithmetic Expressions ............ 156 6.4 Convenience .................................... 159 6.5 Negation and Control .............................. 160 6.6 Unification and Comparison of Terms ..................... 163 6.6.1 Sorting of Terms ............................. 169 6.7 Meta-Logical ................................... 170 6.8 Cyclic Terms ..................................
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]
  • Intercepting Functions for Memoization Arjun Suresh
    Intercepting Functions for Memoization Arjun Suresh To cite this version: Arjun Suresh. Intercepting Functions for Memoization. Other [cs.OH]. Université de Rennes 1, 2016. English. tel-01410539v1 HAL Id: tel-01410539 https://hal.inria.fr/tel-01410539v1 Submitted on 6 Dec 2016 (v1), last revised 11 May 2017 (v2) HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. ANNEE´ 2016 THESE` / UNIVERSITE´ DE RENNES 1 sous le sceau de l’Universite´ Bretagne Loire En Cotutelle Internationale avec pour le grade de DOCTEUR DE L’UNIVERSITE´ DE RENNES 1 Mention : Informatique Ecole´ doctorale Matisse present´ ee´ par Arjun SURESH prepar´ ee´ a` l’unite´ de recherche INRIA Institut National de Recherche en Informatique et Automatique Universite´ de Rennes 1 These` soutenue a` Rennes Intercepting le 10 Mai, 2016 devant le jury compose´ de : Functions Fabrice RASTELLO Charge´ de recherche Inria / Rapporteur Jean-Michel MULLER for Directeur de recherche CNRS / Rapporteur Sandrine BLAZY Memoization Professeur a` l’Universite´ de Rennes 1 / Examinateur Vincent LOECHNER Maˆıtre de conferences,´ Universite´ Louis Pasteur, Stras- bourg / Examinateur Erven ROHOU Directeur de recherche INRIA / Directeur de these` Andre´ SEZNEC Directeur de recherche INRIA / Co-directeur de these` If you save now you might benefit later.
    [Show full text]
  • Intercepting Functions for Memoization Arjun Suresh
    Intercepting functions for memoization Arjun Suresh To cite this version: Arjun Suresh. Intercepting functions for memoization. Programming Languages [cs.PL]. Université Rennes 1, 2016. English. NNT : 2016REN1S106. tel-01410539v2 HAL Id: tel-01410539 https://tel.archives-ouvertes.fr/tel-01410539v2 Submitted on 11 May 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. ANNEE´ 2016 THESE` / UNIVERSITE´ DE RENNES 1 sous le sceau de l’Universite´ Bretagne Loire En Cotutelle Internationale avec pour le grade de DOCTEUR DE L’UNIVERSITE´ DE RENNES 1 Mention : Informatique Ecole´ doctorale Matisse present´ ee´ par Arjun SURESH prepar´ ee´ a` l’unite´ de recherche INRIA Institut National de Recherche en Informatique et Automatique Universite´ de Rennes 1 These` soutenue a` Rennes Intercepting le 10 Mai, 2016 devant le jury compose´ de : Functions Fabrice RASTELLO Charge´ de recherche Inria / Rapporteur Jean-Michel MULLER for Directeur de recherche CNRS / Rapporteur Sandrine BLAZY Memoization Professeur a` l’Universite´ de Rennes 1 / Examinateur Vincent LOECHNER Maˆıtre de conferences,´ Universite´ Louis Pasteur, Stras- bourg / Examinateur Erven ROHOU Directeur de recherche INRIA / Directeur de these` Andre´ SEZNEC Directeur de recherche INRIA / Co-directeur de these` If you save now you might benefit later.
    [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]
  • 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]
  • A Simple Interface for Non Standard Knowledge Systems (SINKS)
    A Simple Interface for Non Standard Knowledge Systems (SINKS) A Writing Project Presented to The Faculty of the Department of Computer Science San Jose State University In Partial Fulfillment of the Requirement for the Degree Master of Science By Harini Rao December 2003 1 © December 2003 Harini Rao [email protected] ALL RIGHTS RESERVED 2 APPROVED FOR THE DEPARTMENT OF COMPUTER SCIENCE Dr. Christopher Pollett Dr. Archana Sathaye Dr. Suneuy Kim APPROVED FOR THE UNIVERSITY 3 Abstract Deductive database systems combine a declarative style for formulating queries and constraints with efficient and reliable database technology for mass-memory data storage. They have the ability to use a logic programming style for expressing deductions concerning the contents of a database. Currently, most of the deductive-style databases such as NAIL!, LDL, CORAL, XSB, etc. usually act as front-ends to a more traditional relational database. It might make it easier to deploy a deductive database system as a back end for a relational database since, then only, the designer of the database needs to understand the non-standard knowledge system and the application programmers can use the SQL they know and love. The purpose of this project is to develop an interface system whereby non-standard knowledge systems such as XSB can make their resources available as a backend to a more traditional relational database, Oracle. 4 Table of contents Page 1. Introduction …………………………………………………………....6 2. Deductive Databases …………………………………………………..8 3. XSB ……………………………………………………………………26 4. Oracle–XSB Interface …………………………………………………29 5. Design ………………………………………………………….………31 6. Implementation ………………………………………………………...36 7. Applications …………………………………………………….……..56 8. Future Enhancements …………………………………………………58 9. Conclusion …………………………………………………………….60 Bibliography ……………………………………………………………62 5 1.Introduction The relational data model is the most well-known and widely used data model.
    [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]
  • The XSB System Version 3.7 Volume 2: Interfaces and Packages
    The XSB System Version 3.7 Volume 2: Interfaces and Packages July 6, 2016 Credits Packages and interfaces have become an increasingly important part of XSB. They are an important way to incorporate code from other systems into XSB, and to interface XSB to databases and other stores. Most of the packages had significant contributions by people other than the core XSB developers, for which we are grateful. As a result most chapters have information about its authors. Contents 1 XSB-ODBC Interface1 1.1 Introduction....................................1 1.2 Using the Interface................................2 1.2.1 Connecting to and Disconnecting from Data Sources.........2 1.2.2 Accessing Tables in Data Sources Using SQL..............3 1.2.3 Cursor Management...........................5 1.2.4 Accessing Tables in Data Sources through the Relation Level.....6 1.2.5 Using the Relation Level Interface....................6 1.2.6 Handling NULL values..........................8 1.2.7 The View Level Interface......................... 10 1.2.8 Insertions and Deletions of Rows through the Relational Level.... 13 1.2.9 Access to Data Dictionaries....................... 14 1.2.10 Other Database Operations....................... 15 1.2.11 Transaction Management......................... 15 1.2.12 Interface Flags.............................. 16 1.2.13 Datalog.................................. 17 1.3 Error messages.................................. 17 1.4 Notes on specific ODBC drivers......................... 18 2 The New XSB-Database Interface 19 2.1 Introduction.................................... 19 2.2 Configuring the Interface............................. 19 2.3 Using the Interface................................ 22 i CONTENTS ii 2.3.1 Connecting to and Disconnecting from Databases........... 22 2.3.2 Querying Databases........................... 24 2.4 Error Handling.................................
    [Show full text]
  • The XSB System Version 2.4 Volume 1: Programmer's Manual
    The XSB System Version 2.4 Volume 1: Programmer’s Manual Konstantinos Sagonas Terrance Swift David S. Warren Juliana Freire Prasad Rao Baoqiu Cui Ernie Johnson with contributions from Steve Dawson Michael Kifer July 13, 2001 Credits Day-to-day care and feeding of XSB including bug fixes, ports, and configuration man- agement has been done by Kostis Sagonas, David Warren, Terrance Swift, Prasad Rao, Steve Dawson, Juliana Freire, Ernie Johnson, Baoqiu Cui, Michael Kifer, and Bart Demoen. In Version 2.4, the core engine development of the SLG-WAM has been mainly imple- mented by Terrance Swift, Kostis Sagonas, Prasad Rao, and Juliana Freire. The break- down, roughly, was that Terrance Swift wrote the initial tabling engine and builtins. Prasad Rao reimplemented the engine’s tabling subsystem to use tries for variant-based table access while Kostis Sagonas implemented most of tabled negation. Juliana Freire revised the table scheduling mechanism starting from Version 1.5.0 to create a more efficient engine, and implemented the engine for local evaluation. Starting from XSB Version 2.0, XSB includes another tabling engine, CHAT, which was designed and developed by Kostis Sagonas and Bart Demoen. CHAT supports heap garbage collection (both based on a mark&slide and on a mark&copy algorithm) which was developed and implemented by Bart Demoen and Kostis Sagonas. Memory expansion code for WAM stacks was written by Ernie Johnson and Bart De- moen, while memory management code for CHAT areas was written by Bart Demoen and Kostis Sagonas. Rui Marques improved the trailing of the SLG-WAM and rewrote much of the engine to make it compliant with 64-bit architectures.
    [Show full text]
  • Programming in Tabled Prolog (Very) DRAFT 1
    Programming in Tabled Prolog (very) DRAFT 1 David S. Warren Department of Computer Science SUNY @ Stony Brook Stony Brook, NY 11794-4400, U.S.A. February 28, 2020 1This is a very early draft made available privately for those who might find it of interest. I reserve all rights to this work. -dsw Contents 1 Background and Motivation 1 2 Introduction to Prolog 6 2.1 Prolog as a Procedural Programming Language . ........... 6 2.1.1 Assign-onceVariables . ..... 7 2.1.2 Nondeterminism ................................ 11 2.1.3 ExecutingProgramsinXSB. 13 2.1.4 The Scheduling of Machine Execution in Prolog . .......... 18 2.2 GrammarsinProlog ................................ 21 2.3 PrologasaDatabaseQueryLangauge . ........ 26 2.4 DeductiveDatabases .............................. ...... 27 2.5 Summary ......................................... 30 2.6 Exercises ....................................... 30 2.7 ExerciseDiscussion.............................. ....... 32 3 Introduction to First-Order Logic 34 3.1 PropositionalLogic.............................. ....... 36 3.1.1 Syntax........................................ 36 3.1.2 Semantics..................................... 36 i CONTENTS ii 3.1.3 Deduction..................................... 38 3.1.4 HornClauses ................................... 41 3.2 FirstOrderLogic(FOL). .. .. .. .. .. .. .. .. ...... 44 3.2.1 Syntax........................................ 44 3.2.2 Semantics..................................... 46 3.2.3 Deduction..................................... 49 3.3 Exercises ......................................
    [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]