RESTIVO@SU-SCORE.ARPA (06/24/85)
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@SU-SCORE.ARPA>
PROLOG Digest Monday, 24 Jun 1985 Volume 3 : Issue 27
Today's Topics:
Query - KBS/DBS Coupling
Implementations - Thanks & Gripe & WPE
----------------------------------------------------------------------
Date: Fri, 14-Jun-85 08:24:23 PDT
From: (IJme Schilstra) oce-rd1!oce-rd2!ysc@Seismo
Subject: KBS/DBS Coupling
I'd like to know about research (as well as commercial
products, if there are) dealing with the coupling of
knowledge base systems (particularly those written in
Prolog) with relational data base systems. (I've access
to INGRES on a VAX 11/750 under UNIX BSD 4.1, but I'm
interested in other DBMS's being used too.) Please mail
me:
(1) Commercial products
(a) Manufacturer
(b) Product description
(c) Application area
(d) Experiences
(2) Research
(a) Project description
(b) Relational DBMS being used
(c) Prolog version being used
(or more general: knowledge
base system implementation)
(d) Application area (if any)
(e) Experiences
Thanks very much,
-- IJme Schilstra
------------------------------
Date: Mon, 10-Jun-85 16:21:10 PDT
From: (Michael O'Hair) tektronix!michaelo@UCB-Vax
Subject: Thanks you
I want to thank all those who took the time to offer
assistance. My main problem stems from making an assumption
about a system library. There was no rules defined for
'append' so the interpreter balked. Once I put in a
set of rules, things work fine. Spoiled by 'C', I guess.
:-)
The next question is: what is the preferred way of
developing a system library and implementing an "includes"
file?
As always, any and all information is appreciated.
Thanks again.
-- Michael O'Hair
------------------------------
Date: Sun 16 Jun 85 16:34:38-PDT
From: Pereira@SRI-AI
Subject: Bugs, more bugs...
If anyone doubted the urgent need for a Prolog standard and
test suite, the increase of messages of the form ``The
Prolog system I got from Dr. Il Logical is behaving
strangely and my students are crying over their terminals''
is a clear indication of the lack of any accepted means to
test the performance and reliability of Prolog systems.
I fear that people may be turned away from Prolog, not
because of its REAL limitations (which are inevitable in
any engineering compromise) but because of contact with
unreliable or slow implementations that do not do justice
to the language. The Prolog community must put its house
in order, by establishing an accepted standard to have a
means to distinguish between non-problems (``Slimylog blows
up without warning when reading a term with more that 27
subterms'') and real problems (``what is the best approach
to add an equational component to Horn clauses'').
The best standards (the only possible ones...?) are those
based on successful current practice. Standard committees
should not engage in design tasks that are better left to
researchers. Instead, they should look in a non-partisan
manner at the actual practice (what systems are most
successful: satisfied customers, big applications, performance,
time in the field; what features are used by programmers,
what do they miss) and build a standard that helps
education and programming by setting a framework to
evaluate existing systems and new extensions. It is a
somewhat unglamorous task, hammering a standard that will not
include all those exciting new ideas that we may be
implementing next week. But it needs to be done.
-- Fernando Pereira
------------------------------
Date: Thu, 13 Jun 85 17:41:46 -0100
From: Burkhard Neidecker <neideck%germany@csnet-relay>
Subject: WPE variable handling
I would like to answer the question roused by David M.
Meyer in Vol3#26 concerning the handling of temporal vari-
ables in the WPE. The example given by him contained
several misconceptions about the handling of variables in
the WPE. We have implemented the WPE in C here at Karlsruhe,
so we have some insight into the concepts that guided War-
ren.
The first misconception is that a variable is no longer
accessed after its last occurrence in a clause. In general
it is still accessible for all subsequent goals (subgoals as
well as continuation) via its reference put into a register
or heap slot:
a) p1 :- p2(T).
b) p2(P) :- p3(...),p4(P),...
Clause a) is just
put_variable X2,A1 % Put T
execute p2/1
The head of b) translates into
get_variable Yn,A1
which internally is simply an assignment. Suppose, the
internal operation of put_variable Xn,Ai would be
Ai := Xn := ref_to(Ai)
as suggested by David Mayer, then Yn in b) would receive a
reference to A1 while executing get_variable Yn,A1. Only
heaven knows what the contents of A1 will be after execution
of all the subgoals of p3. Thus p4 would be called with a
wrong parameter. To avoid such clashes without using a glo-
bal register allocator, you have to use a distinct memory
location for variables instead of a register reference.
The second misconception is a variable classification
different from that proposed by Warren in his SRI TR 309
paper. I assume, the use of Z in the head was a typing error
(otherwise, Z would be permanent), so the clause should
perhaps really have been:
f(X,Y,_) :- h(Q), g(Y,Z).
David Meyer classified Q as temporary, while according to
Warren it should be permanent:
"A temporary variable is a variable that (1) has its
first occurrence in the head or in a structure or in
the last goal, and (2) that does not occur in more than
goal in the body, where the head is counted as part of
the first goal.
The head is considered part of the first goal only in
respect to condition (2)! Q neither occurs first in the
head nor in in a structure, thus it is classified a *per-
manent* variable.
Warrens apparently intricate classification scheme is
driven by two different considerations:
(1) All variables supporting "dataflow" between different
goals in the body must be located in an environment
because the registers might be overwritten by subgoal
execution.
(2) Whenever possible, space is allocated on the local
stack where it can be subject to tail recursion optimi-
zation.
If a variable occurs first in a body goal, you *have* to
allocate a cell for it (see above). If it occurs in a struc-
ture, you will need a global cell anyway, so there is no
extra penalty. In the last goal, you don't have any choice
as on which stack to allocate the cell, since at this point
your environment (if any) will have become deallocated. Thus
you are forced to get a global cell which is exactly what
the put_variable Xn,Ai instruction does.
As long as you are in the middle of the body, you may
allocate your storage from the local stack, retain the allo-
cated cells throughout the very next call and then deallo-
cate them (together with all subgoals which might have
references to that cells) by virtue of the following *call*
or *deallocate* instruction.
Thus the correct code for the given clause (redundant
instructions included) should be:
f(X,Y,_) :- h(Q), g(Y,Z).
allocate
/* get_variable X1,A1 */ % X
get_variable Y1,A2 % Y
/* get_variable X3,A3 */ % _
put_variable Y2,A1 % Q : allocate
% local cell and
call h/1,2 % keep it for this
% call
put_value Y1,A1 % ***
put_variable X3,A2 % Since
% environment
% becomes
deallocate % deallocated
execute g/2
*** David Mayer used put_unsafe_value
here, which is unnecessary
Upon deterministic return from h/1, the cell for Q can be
safely reclaimed.
-- Burkhard Neidecker
------------------------------
End of PROLOG Digest
********************