POPX@VAX.OXFORD.AC.UK (12/07/87)
From: Jocelyn Paine,
St. Peter's College,
New Inn Hall Street,
Oxford OX1 2DL.
Janet Address: POPX @ OX.VAX
PROLOG SOURCE LIBRARY
I teach AI to undergraduates, as a one-term practical course in the
Experimental Psychology degree. For the course, I use Poplog Prolog, on
a VAX under VMS. During the course, I talk about topics like scripts,
mathematical creativity, planning, natural language analysis, and expert
systems; I exemplify them by mentioning well-known programs like GPS,
Sam, and AM.
I would like my students to be able to run these programs, and to
investigate their mechanism and limitations. For students to incorporate
into their own programs, I'd also like to provide a library of Prolog
tools such as chart parsers, inference engines, search routines, and
planners. Unfortunately, published descriptions of the famous programs
give much less information than is necessary to re-implement them. As
for tools like planners and inference engines: the literature is often
more helpful, but I still have to do a lot of work which must have been
done before, even if it's merely typing in code from excellent textbooks
like "The Art of Prolog".
I'm sure other Prolog programmers have this problem too.
I have therefore set up a LIBRARY OF PROLOG SOURCE CODE, which I will
distribute over the British academic network (Janet) and nets like
Bitnet connected to Janet, to anybody who wants it. I will take
contributions from anyone who wants to provide them, subject to a few
conditions mentioned below. I proposed this in AIList Bulletin V5 267:
here are the details of how the library works. If you want to contribute
entries, or to request them, please read on...
How to send contributions.
Please send Prolog source for the library, to user POPX at Janet
address OX.VAX (the Vax-Cluster at Oxford University Computing
Service). If a file occupies more than about 1 megabyte, please send a
short message about it first, but don't send the large file itself
until I reply with a message requesting it. This will avoid the
problems we sometimes have where large files are rejected because
there isn't enough space for them.
I accept source on the understanding that it will be distributed to
anyone who asks for it. I intend that the contents of the library be
treated in the same way as (for example) proofs published in the
mathematical literature, and algorithms published in computer science
textbooks - as publicly available ideas which anyone can experiment
with, criticise, and improve.
I will try to put an entry into the library within one working week of
its arrival.
Catalogue of entries.
I will keep a catalogue of contributions available to anyone who asks
for it.
The catalogue will contain for each entry: the name and geographical
address of the entry's contributor (to prevent contributors receiving
unwanted electronic mail, I won't include their electronic mail
addresses unless I'm asked to do so); a description of the entry's
purpose; and an approximate size in kilobytes (to help those whose
mail systems can't receive large files easily).
I will also include my evaluations of its ease of use, of its
portability and standardness (by the standards of Edinburgh Prolog);
and my evaluation of any documentation included.
Quality of entries.
Any contribution may be useful to someone out there, so I'll start by
accepting anything. I'm not just looking for elegant code, or logical
respectability. However, it would be nice if entries were to be
adequately documented, to come with examples of their use, and to run
under Edinburgh Prolog as described in "Programming in Prolog" by
Clocksin and Mellish. If you can therefore, I'd like you to follow the
suggestions below.
The main predicate or predicates in each entry should be specified
so that someone who knows nothing about how they work can call them.
This means specifying: the type and mode of each argument, including
details of what must be instantiated on call, and what will have
become instantiated on return; under what conditions the predicate
fails, and whether it's resatisfiable; any side-effects, including
transput and clauses asserted or retracted; whether any initial
conditions are required, including assertions, operator
declarations, and ancilliary predicates. In some cases, other
information, like the syntax of a language compiled by the
predicate, may be useful.
A set of example calls would be useful, showing the inputs given,
and the outputs expected. Use your discretion: if you contribute an
expert system shell for example, I'd like a sample rulebase, and a
description of how to call the shell from Prolog, and some
indication of what questions I can ask the shell, but I don't
require that the shell's dialogue be reproduced down to every last
carriage return and indentation.
For programmers who want to look inside an entry, adequate comments
should be given in the source code, together perhaps with a more
general description of how the entry works, including any relevant
theory.
In the documentation, references to the literature should be given,
if this is helpful.
Entries should be runnable using only the predicates and operators
described in "Programming in Prolog" (if they are not, I may not be
able to test them!). I don't object to add-on modules being included
which are only runnable under certain implementations - for example,
an add-on with which a planner can display its thoughts in windows
on a high-resolution terminal - but they will be less generally
useful.
As mentioned earlier, I will evaluate entries for documentation and
standardness, putting my results into the catalogue. If I can, I
will also test them, and record how easy I found them to use, by
following the instructions given.
I emphasise that I will accept all entries; the comments above suggest
how to improve the quality of entries, if you have the time.
Requesting entries.
I can't afford to copy lots of discs, tapes, papers, etc, so I can
only deal with requests to send files along the network. Also, I can't
afford to send along networks that I have to pay to use from Janet.
You may request the catalogue, or a particular entry in it. I will
also try to satisfy requests like "please send all the natural
language parsers which you have" - whether I can cope with these will
depend on the size of the library.
I will try to answer each request within seven working days. If you
get no reply within fourteen working days, then please send a message
by paper mail to my address. Give full details of where your
electronic mail messge was sent from, the time, etc. If a message
fails to arrive, this may help the Computing Service staff discover
why.
Although I know Lisp, I haven't used it enough to do much with it,
though I'm willing just to receive and pass on Lisp code, and to try
running it under VAX Lisp or Poplog version 12 Lisp.POPX@VAX.OXFORD.AC.UK (07/26/88)
Date: Mon, 25 Jul 88 18:22 EDT
From: POPX%VAX.OXFORD.AC.UK@MITVMA.MIT.EDU
To: ailist@AI.AI.MIT.EDU
Subject: Prolog Source Library
From: Jocelyn Paine,
St. Peter's College,
New Inn Hall Street,
Oxford OX1 2DL.
(mail address only; please don't phone).
Janet Address: POPX @ OX.VAX
PROLOG SOURCE LIBRARY
About 6 months ago, I announced the Prolog Source Library of public
domain software. Anyone can send or contribute. I haven't had as many
entries as I'd hoped (gentle hint: several subscribers said they'd send
things, and haven't yet); and there must be new readers who don't know
of it. So this is a reminder.
I shall follow with details of how the library works, and end with a
summary of the catalogue so far. If you want to contribute entries, or
to request them, please read on...
SENDING AND GETTING:
How to send contributions.
Please send source for the library, to user POPX at Janet address
OX.VAX (the Vax-Cluster at Oxford University Computing Service). If a
file occupies more than about 1 megabyte, please send a short message
about it first, but don't send the large file itself until I reply
with a message requesting it. This will avoid the problems we
sometimes have where large files are rejected because there isn't
enough space for them.
I accept source on the understanding that it will be distributed to
anyone who asks for it. I intend that the contents of the library be
treated in the same way as (for example) proofs published in the
mathematical literature, and algorithms published in computer science
textbooks - as publicly available ideas which anyone can experiment
with, criticise, and improve.
I will try to put an entry into the library within one working week of
its arrival.
Catalogue of entries.
I will keep a catalogue of contributions available to anyone who asks
for it.
The catalogue will contain for each entry: the name and geographical
address of the entry's contributor (to prevent contributors receiving
unwanted electronic mail, I won't include their electronic mail
addresses unless I'm asked to do so); a description of the entry's
purpose; and an approximate size in kilobytes (to help those whose
mail systems can't receive large files easily).
I will also include my evaluations of its ease of use, of its
portability and standardness (by the standards of Edinburgh Prolog);
and my evaluation of any documentation included.
Quality of entries.
Any contribution may be useful to someone out there, so I'll start by
accepting anything. I'm not just looking for elegant code, or logical
respectability. However, it would be nice if entries were to be
adequately documented, to come with examples of their use, and to run
under Edinburgh Prolog as described in "Programming in Prolog" by
Clocksin and Mellish. If you can therefore, I'd like you to follow the
suggestions below.
The main predicate or predicates in each entry should be specified
so that someone who knows nothing about how they work can call them.
This means specifying: the type and mode of each argument, including
details of what must be instantiated on call, and what will have
become instantiated on return; under what conditions the predicate
fails, and whether it's resatisfiable; any side-effects, including
transput and clauses asserted or retracted; whether any initial
conditions are required, including assertions, operator
declarations, and ancilliary predicates. In some cases, other
information, like the syntax of a language compiled by the
predicate, may be useful.
A set of example calls would be useful, showing the inputs given,
and the outputs expected. Use your discretion: if you contribute an
expert system shell for example, I'd like a sample rulebase, and a
description of how to call the shell from Prolog, and some
indication of what questions I can ask the shell, but I don't
require that the shell's dialogue be reproduced down to every last
carriage return and indentation.
For programmers who want to look inside an entry, adequate comments
should be given in the source code, together perhaps with a more
general description of how the entry works, including any relevant
theory.
In the documentation, references to the literature should be given,
if this is helpful.
Entries should be runnable using only the predicates and operators
described in "Programming in Prolog" (if they are not, I may not be
able to test them!). I don't object to add-on modules being included
which are only runnable under certain implementations - for example,
an add-on with which a planner can display its thoughts in windows
on a high-resolution terminal - but they will be less generally
useful.
As mentioned earlier, I will evaluate entries for documentation and
standardness, putting my results into the catalogue. If I can, I
will also test them, and record how easy I found them to use, by
following the instructions given.
I emphasise that I will accept all entries; the comments above suggest
how to improve the quality of entries, if you have the time.
Requesting entries.
I can't afford to copy lots of discs, tapes, papers, etc, so I can
only deal with requests to send files along the network. Also, I can't
afford to send along networks that I have to pay to use from Janet.
You may request the catalogue, or a particular entry in it. I will
also try to satisfy requests like "please send all the natural
language parsers which you have" - whether I can cope with these will
depend on the size of the library.
I will try to answer each request within seven working days. If you
get no reply within fourteen working days, then please send a message
by paper mail to my address. Give full details of where your
electronic mail messge was sent from, the time, etc. If a message
fails to arrive, this may help the Computing Service staff discover
why.
Although I know Lisp, I haven't used it enough to do much with it,
though I'm willing just to receive and pass on Lisp code, and to try
running it under VAX Lisp or Poplog version 13 Lisp.
I will also accept Pop-11 code. Depending on what happens to the Poplog
Users' Group library (policy is being decided now), I'll either add the
code to a Pop-11 section of my library, or pass it on to PUG.
THE CATALOGUE SO FAR:
TURTLE GRAPHICS
Contributed by Salleh Mustaffa, University of Manchester
Copyright (c) 1987 by David Lau-Kee, Univ. of York.
Simple Prolog turtle package, for VT100 or similar.
TYPE-CHECKER
Contributed by R.A.O'Keefe
Authors: Alan Mycroft & R.A.O'Keefe
(This program was sent to the Prolog Digest on the 14th of November,
1987.)
Defines a way to specify a type for each predicate, and a type-checked
"consult" which checks goals against the type of the predicate called.
GRAMMAR-RULE TRANSLATOR
Jocelyn Paine
Defines a predicate, 'grexpand', for expanding Definite Clause Grammar
Rules into Prolog clauses. These are the standard form of DCG rules, for
which a translator is built-in to many Prologs.
The translator is essentially the same as that published in "Programming
in Prolog", by Clocksin and Mellish.
DOUBLY-LINKED LIST PACKAGE
Contributed by Philip Dart, Melbourne University
Doubly-linked list-handling package sent to the Prolog Digest on 14th of
November by Philip Dart, Melbourne University. Creates cyclic structures
along whicch you can move in either direction.
FILE SEPARATOR
Jocelyn Paine
Allows one to separate text files which have been concatenated into a
larger file. Mainly useful to separate files belonging to the Prolog
Library which have been packed in this way.
OBJECT-ORIENTED PACKAGE
Author: Ben Staveley-Taylor
This program - called POEM by its author - comes from a Poplog Users'
Group tape, received in early 1987.
POEM makes available some of the features found in languages like
Simula-67. Classes may be defined, objects (instantiations of classes)
created and operated on as high- level entities.
UTILITIES
Contributed by Bert Shure, SUN Microsystems
Written by John Cugini, National Bureau of Standards
Various utility predicates, some commonly used, some not.
Predicates include: member; append; maplist; other list-handling
predicates; predicates for handling sets represented as lists;
type-testing predicates; sorting and merging; readline; a predicate for
getting the printable representation of a term; rational number
predicates; meta-logical predicates for dealing with true disjunction
and negation.
PREDICATE AUTO-TESTER
Jocelyn Paine
Reads a file or files of Prolog goals, where each goal is accompanied by
a specification saying whether it should succeed, fail, cause an error,
or pass some tests on its bound variables.
For each goal/specification pair, the program calls the goal, and
compares its effect with the specification. If they differ, then a
warning message is displayed. Useful for automatically testing
predicates against their expected outputs.
INTERVAL-ALGEBRA PREDICATES
Jocelyn Paine
Shelved on the 21st of December 1987
Predicates for manipulating sets of integers, represented as lists of
disjoint intervals. This is a compact way of representing large sets,
provided that they contain few gaps between intervals.
CURSOR-ADDRESSING PREDICATES
Jocelyn Paine
Shelved on the 21st of December 1987
There are two sets of predicates, one for VT100s and one for VT52s.
They: move to X,Y; clear a line or page; set inverse or normal video.
LIST-HANDLING PREDICATES
Contributed by J.G. Forero, Reading University
The predicates' functions are: test for list-ness; test for sublist;
find element at known position, or position of known element; remove
duplicates; flatten a list; add element after known element; find that
part of a list following a given element.
EXPERT SYSTEM FOR FORESTRY MANAGEMENT
Contributed by Steve Jones, Reading University
A small expert system for forestry management.
LINGER:
A TOOL FOR GRAMMAR ANALYSIS OF WESTERN EUROPEAN LANGUAGES
Contributed by Paul O'Brien and Masoud Yazdani, Exeter University
LINGER is a language-independent system to analyse natural language
sentences and report and correct grammatical errors encountered. An
important objective is that the system should be easily configured for a
particular natural language by an expert in that language but not in
computer science.
Only a French grammar is available.
EDINBURGH TOOLS
Contributed by the AI Applications Institute, Edinburgh University
The DEC-10 Prolog Library was an extraordinary and catholic collection of
Prolog routines, largely written by research workers and students in Professor
Alan Bundy's Mathematical Reasoning Group at the Department of Artificial
Intelligence at the University of Edinburgh. In summer 1987 we sifted through
the enormous amount of material in this library, grouping similar material
together and converting some of the more used programs into Edinburgh Prolog.
These programs are all examples of Prolog programming to deal with objects and
problems of many kinds. (Some of these examples are very good examples, others
are not so; some are well commented, some have separate documentation, some
have none.) You may be able to load tools for low-level operations into your
code ready-made, or you may gain insight into how to write good Prolog (as we
did) through just browsing amongst the source code here.