[net.lang.prolog] PROLOG Digest V3 #32

RESTIVO@SU-SCORE.ARPA (07/15/85)

From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>


PROLOG Digest            Monday, 15 Jul 1985       Volume 3 : Issue 32

Today's Topics:
                   Query - Building Large Systems,
    Implementation - Cut & A Standard Syntax & Conditionalization
----------------------------------------------------------------------

Date: Thu, 11 Jul 85 14:30 EST
From: Robert France <France%vpi@csnet-relay>
Subject: Prolog for Building Large Systems

What have your experiences been with using your favorite
Prolog in large system contruction?  What Prolog would
you recommend for building something substantial?

We are currently designing a system here that will apply
techniques of expert systems and knowledge engineering to
the task of information retrieval from very large text
databases.  For reasons of software engineering and general
godliness, we would like to take a modular approach to this
project; for reasons of efficency, we may want to code
portions of it in a procedural language (C by concensus);
but for other obvious reasons, we would like to build the
cooperating experts in Prolog.

We currently are using a local lisp-syntax Prolog which,
although a very nice little language for prototyping, is
inadequate for the project in several ways.  What we need
is a Prolog that:

-- supports modularity, either within the language, or through
   appropriate process-control primitives,

-- has a workable interface with (at least one) procedural
   language (preferably C), and/or

-- directly suports large, fast database functions.

If you have any knowledge of or experience with a Prolog
with some ofthese features, please take the time to tell us
about it.  We will, of course, summarize the results and
post them back to this Digest.

Thank you all,

-- Robert France

------------------------------

Date: 11 July 85 23:30-EDT
From: BYKAT%UTCVM.BITNET@Berkeley
Subject: Chris Moss Cut-Test results

I have run Chris Moss' tests on our MPROLOG Version1.5
supplied by Logicware and running under VM/CMS on an IBM
4381.  Here are the results:

Implementation     Test 1  2  3  4  5  6
MProlog                 Y  Y  Y  Y  N  N

-- Alex Bykat

------------------------------

Date: Mon, 8-Jul-85 10:51:54 PDT
From: (Frank McCabe) mcvax!ukc!icdoc!fgm@Seismo
Subject: A Standard Syntax

The standard micro-Prolog system includes a package
which 'translates' between the 'standard' (quotes
intentional) Edinburgh syntax and micro-Prolog syntax.
This doesn't do a particularly good job on standard
micro-Prolog although the  systems on sigma-Prolog
and Mac-Prolog do a great deal better.

The problems over semantics are very hard to solve; however
not even Edinburgh Prolog systems agree over how to
implement cut!  (For proof of this see C.D.Moss's
article on the differences between cut on various systems).

------------------------------

Date: Fri, 12 Jul 85 00:08 EDT
From: Tim Finin <Tim%upenn@csnet-relay>
Subject: Read Time Conditionalization

I'm not sure what Peter Deutsch means by "structure-based
(as opposed to file-based) environments" but it seems to
me that it is neccessary to handle differences at the reader
level.  I am assuming that "structure-based" refers to the
ability to have things behave differently in environments
which differ after the reader has done its job.

Actually, what I have in mind really has two independent
parts:

(1) having a standard way one can find out if a particular
Prolog instantiation does or does not have a particular
"feature" (e.g. is C-Prolog running on a VAX under BSD4.2)

(2) having a mechanism to make the reader sensitive to
these features.

One can use (1) to achieve "structure-based" environments,
if I understand the term correctly, with out resorting to
(2).  I believe that (2) is neccessary to handle
reader-level differences and useful for several other
reasons (e.g. efficiency).

One problem I forsee with (1) is having some consensus on
what a feature is and agreeing on some standard ones (e.g.
names for common machines and operating systems).  This
does not seem to have been a big problem in the Common
Lisp family, however.

-- Tim

------------------------------

Date: 12 Jul 85 9:11:56 PDT
From: Deutsch.pa@Xerox.ARPA
Subject: Read Time Conditionalization

By a "structure-based" environment, I mean one like
Interlisp, where the tools are based on structures held
within the address space rather than on external text
files manipulated by a foreigneditor.  An apparent
requirement for such a system (which I believe makes
the construction of tools easier than a file-based
system -- you don't have to be constantly worrying about
manipulating things that have language-relevant semantics
but are represented as character strings) is that the
reader doesn't lose any information that the programmer
cares about.  Read-time conditionalization doesn't have
this property, unless it is done in a very arcane manner
using something like hash links to remember the information
that is discarded from the list structure.

Maclisp and Zetalisp (and apparently Common Lisp) all take
the opposite view, that the tools are at least partly file
based and the editor is a text editor.  While this is
obviously a workable approach, I suspect it is part of the
reason why it took so long for that world to develop
retrieval tools anywhere near as good as Masterscope, for
example.

------------------------------

End of PROLOG Digest
********************