Quintus/SWI Prolog Portability Suite

Table of Contents

Purpose

Quintus and SWI have provided Prolog systems that are very close in their implementations. This is no surprise, as one of the stated goals in the SWI implementation was to follow Quintus' as closely as possible. In many and major ways these two implementations agree, but over time differences have crept into their implementations that now require external intervention in order to allow programs to run on either systems.

As such, I have developed a set of modules that provide to one language implementation the specific protocols of the other. These modules address the most common set of differences between the two implementations. Esoteric features (such as SWI's arithmetic_function/1 or Quintus' with_output_to_chars syntax) certainly extend an implementation's expressivity, but are not addressed by these modules. Caveat user.

Introduction

The portability suite contains two directories: quintus/ that contains a set of modules that provide some common protocols of Quintus' Prolog to SWI (to allow programs implemented in Quintus Prolog to run in SWI), and swi/ that provides the readutil module for use by programs written for SWI Prolog so that they may run in Quintus Prolog. This document covers the modules in each of these directories.

Usage

To use the portability suite in the SWI environment, add the quintus/ module set to the file_search_path/2 predicate with an assert/1. Similarily for Quintus Prolog, add the swi/ module URI to the file_search_path/2.

Quintus Modules

The set of these quintus/ modules provide mostly empty protocols and faux-implementations to provide the bare set of essential linkages to the desired functionality. SWI Prolog already implements most of this functionality at the top-level or by import (from the provided quintus module, included with the distribution), but import statements in source files developed in a Quintus environment specifying module or predicate imports will cause errors and warnings when loaded in SWI. These modules have the aim of using available SWI resources without needing to alter the ported program.

:- module(basics).

Description:
Facilitates porting applications between Quintus and SWI by providing skeletal implementations of these Quintus modules to SWI. This module is supposed to export member/2, but SWI already has that in module(user).
Exported Predicates:
n/a

:- module(date).

Description:

Gives a faux-implementation of time_stamp/2, mostly for the unit test case suite's use. Also, as Quintus puts date/1 into this module namespace (it is available to SWI at the top level module(user)), this module bridges the use_module/1 call in Quintus to SWI's direct use.

Exported Predicates:
time_stamp(+Format, -Date)
where:
Format<atom> Encoded formatting information; currently ignored
Date<atom> Current date output in the format as per Format
N.B.:

The first argument is a formatting atom/string, instructing time_stamp/2 how to render the date/3 term (representing today's date) for the DateAtom result. However, as the unit test case suite is the only current user of this predicate, it ignores the Format argument, simply giving the result in a statically-defined format.

When it occurs that multiple using modules need differing date formats, I will flesh out this predicate's implementation.

:- module(math).

Description:
Facilitates porting applications between Quintus and SWI by providing skeletal implementations of these Quintus modules to SWI. This module is supposed to export floor/2, etc., but SWI already has that at the top level in module(user).
Exported Predicates:
n/a

:- module(print_chars).

Description:
Asserts portray/1 clauses that scans lists to see if they can be portrayed as strings instead of comma-separated lists of ordinals.
Exported Predicates:
n/a

:- module(strings).

Description:
Quintus puts concat_atom/2 into this module's namespace, but it is available in SWI at the top level. This module bridges these differing implementations.
Exported Predicates:
n/a

SWI Modules

So far this side of the portability suite has only one module: readutil. Ease of interacting with (file) streams is a Unix innovation. As Prolog predates Unix, one sees the rather unenlightened approach to stream processing in the older implementations of the language. SWI embraces some of the advances in stream processing with predicates implemented modules supporting this paradigm introduced by Unix. This suite (granted: it's only one module so far) provides this functionality to Quintus.

:- module(readutil).

Description:
Gives the ability to read a file in as a string, à la SWI readutil module.
Exported Predicates:
read_file_to_codes(+Filename, -String, +Options)
where:
Filename<atom> Name of file to read in
String<list of codes> The file's contents
Options<list of file parameters> ignored
N.B.:
The Options list provides SWI with information on how the file should be opened and the resulting String representation. As we use read_file_to_codes/3 derivatively, the Options are currently ignored.
author: Douglas M. Auclair (dauclair at hotmail dot com)
date:December 16, 2005
Copyright © 2005, Cotillion Group, Inc. All rights reserved.