PROLOG-REQUEST@SUSHI.STANFORD.EDU.UUCP (03/12/87)
PROLOG Digest Thursday, 12 Mar 1987 Volume 5 : Issue 14
Today's Topics:
Query - Search Reorganization,
Implementation - Clarification & Turbo Opinion
Announcement - Colloquium (UPenn)
----------------------------------------------------------------------
Date: 11 Mar 87 06:07:11 GMT
From: Peter Wu <pics!wup@seismo.css.gov>
Subject: Search re-organization in Compilation
I am looking for references of work done on Prolog implementations
concerning Database search strategies. We often want to search the
database with partially instantiated keys. How much work was done
on organizing the strategy for search? I heard of dramatic improve-
ments on performance when search strategy is done right. I believe
this is related - or even actually - same as query optimization for
relational database management system. I may organize the references
and post them, if it deems appropriate. Thank you.
-- Peter Y.F. Wu
------------------------------
Date: Wed, 11 Mar 87 09:37:03 PST
From: Fernando Pereira <pereira@sri-candide.ARPA>
Subject: My noncontribution to Turbo-Prolog
Rick Innis (Prolog Digest vol. 3 Issue 13) misunderstands Mike Newton's
parenthetical remark ``thanks to Fernando Pereira'' in Mike's discussion
of the (lack of) logical variable in Turbo-Prolog. The thanks are for
pointing out that lack to Mike, not for being responsible for it! I wish
Rick Innis had checked with Mike or me on his reading of Mike's review
before coming out all over the net with a conterfactual paragraph based
on his misreading. He might not be aware of this, but conterfactual
attributions have a way of losing their conterfactual marking when
reproduced: "If Fernando did X then he is a bozo" turns into
"Fernando did X and so he is a bozo" in no time at all...
------------------------------
Date: 10 Mar 87 22:27:23 GMT
From: Mike Newton <newton@csvax.caltech.edu>
Subject: How do you like Turbo-Prolog?
>>> Also, and most seriously (thanks to Fernando Pereira) there are
>>> two more *MAJOR* problems: the logical variable doesn't really
>>> exist: it is a runtime error to do variable-to-variable unifications
By "thanks to Fernando Pereira" I meant "thanks to him for pointing
this out to me". I believe he was as upset as I was about the changes.
- Mike Newton
------------------------------
Date: Wed 11 Mar 87 14:26:33-PST
From: Steven Hardy <SHARDY@TEKNOWLEDGE.ARPA>
SUBJECT: TURBO PROLOG
Mike Newton says that Turbo-Prolog does not have 'real' logical
variables and that the following causes a run-time error:
p(X, X).
?- p(X, Y), p(X, a).
I tried this and it worked fine for me.
-- Steve Hardy
------------------------------
Date: 11 Mar 87 16:17:24 GMT
From: Ray Trent <trent@csvax.caltech.edu>
Subject: What Prolog is good?
In article <473@thumper.UUCP> steve@thumper.UUCP writes:
>Earlier I asked the group what they thought of Turbo Prolog. Most
>of you don't seem to like it. I'd like to buy the least expensive
>Prolog that is a Real Prolog for my IBM PC (boy, is that a fuzzy
>set, or what?). Suggestions would be very useful.
Has anyone out there heard of/used a thing called "Wisdom Prolog".
(it's mentioned in the back of "The Art of Prolog" by Sterling &
Shapiro. It's put out by MIT Press, or so I gather)
It is a low cost product intended for the IBM/Mac/Amiga. They also
mention VMS and Unix versions.
Any comments would be appreciated.
------------------------------
Date: 9 Mar 87 15:56:08 GMT
From: Randy Gordon <tektronix!reed!iscuva!randyg@ucbvax.Berkeley.EDU>
Subject: What Prolog is good?
I have used both Turbo and Arity Prolog, and frankly, I prefer Arity.
Type checking really isn't a problem. Since true orthogonal
polymorphism isn't present in EITHER implementation, you have to do it
anyways. Turbo requires it at compiletime, whereas you have to use a
separate Alint program to detect type mismatches in Arity. This is
handy if you are trying to debug a program that may have bugs in areas
you DON'T want to fix immediately(Turbo always stops at each error for
confirmation).
The true usefulness of Arity is due to its 1 Gigabyte virtual memory,
and built in b-tree, hashing and linked list predicates. Even if you
don't need the power of a full Edinburgh Prolog.
Turbo is good if you are doing small stuff, and don't have any need for meta-
circular programming( which almost always means non AI work ), but if you
have never experienced the freedom and creativity of a true Edinburgh Prolog,
you are missing one of the great joys in life. Turbo is a dull, difficult
slogging language by comparison.
-- Randy Gordon
------------------------------
Date: Wed, 11 Mar 87 11:14:21 EST
From: Tim Finin <tim@linc.cis.upenn.edu>
Subject: Colloquium
Colloquium
Computer and Information Science
University of Pennsylvania
A NEW PARALLEL EXECUTION MODEL FOR PROLOG
Barry S. Fagin
Computer Science Division
University of California, Berkeley
Logic programming, or programming with mathematical logic, has been
around since the early 1970's, but has only recently attracted major
interest. This is largely due to the adoption of Prolog as the kernel
language of the Japanese "5th Generation" research effort.
Researchers have expended considerable effort studying Prolog, and it
seems safe to say that the implementation issues of sequential Prolog
are well understood. The next step, then, is to investigate how
Prolog might best be executed on a multiprocessor.
Unfortunately, current attempts to answer this question have been
woefully inadequate, due to the differing approaches of the
theoretician and the computer architect. Theoreticians repeatedly
propose schemes for parallel Prolog that utilize a broad spectrum of
concurrency, but ignore costs associated with process creation and
interprocess communication. Computer architects, on the other hand,
propose models that can be easily mapped onto existing
multiprocessors, but miss potential concurrency.
This talk will present an execution model for Prolog that combines
these two approaches. I will discuss the theoretical significance of
the model, and present a multiprocessor architecture for it. I will
present the most extensive simulation results of a parallel logic
programming system to date, and discuss what I believe the
results indicate.
This talk is entirely self-contained; no familiarity with Prolog
or logic programming is assumed.
------------------------------
End of PROLOG Digest
********************