PROLOG-REQUEST@SUSHI.STANFORD.EDU.UUCP (03/11/87)
PROLOG Digest Wednesday, 11 Mar 1987 Volume 5 : Issue 13
Today's Topics:
Query - Moss Benchmark Programs & Graphics Calls,
Implementation - Turbo Opinions,
Announcement - Incomplete Information
----------------------------------------------------------------------
Date: Tue, 3 Mar 87 09:51:39 PST
From: Chuck Restivo <restivo@sushi.stanford.edu>
Subject: Benchmark Programs
I am looking for Chris Moss' set of files testing Edinburgh syntax,
assert, metacall and cut - please mail them and they'll be installed
in the Library.
-- Chuck
------------------------------
Date: 5 Mar 87 22:02:57 GMT
From: Dave Chassin <rpics!chassin@seismo.css.gov>
Subject: Graphics Calls for C-Prolog on Sun 2
I am lookup for a modification to C-Prolog on a Sun 2 that would allow
me to make ACM Core graphics calls using prolog predicates. The
C-Prolog I am referring to is the one (and only) written at University
of Edinburgh. If anyone has heard of such an extension, please let me
know.
-- David Chassin
------------------------------
Date: 9 Mar 87 14:40:37 GMT
From: mcvax!ukc!its63b!csrdi@seismo.css.gov
Subject: How do you like Turbo-Prolog?
Maybe I'm just spoiled rotten from living where Prolog was first
implemented, but having used three generations of Prolog interpreters I
honestly can't say that Turbo is what I think of as Prolog. When I think
Prolog, I think 'Edinburgh Syntax' - which is, after all, the de facto
standard. The notion of type checking, call it what you will, just
doesn't seeem to me to be part of Prolog.
The article forwarded by Mike Newton seem to ascribe some of these
modifications to Fernando Pereira. If he was reponsible for these, I
must admit to some surprise since he was involved in the early
implementations of DEC-10 Prolog, and really should have known better....
-- Rick Innis
------------------------------
Date: 8 Mar 87 07:06:47 GMT
From: J. Peter Alfke <alfke@csvax.caltech.edu>
Subject: How do you like Turbo-Prolog? - (nf)
In article <7000002@iaoobelix.UUCP> wagner@iaoobelix.UUCP writes:
>Roughly speaking, TurboProlog is Pascal with Prolog syntax.
>(Sorry, I couldn't resist (:-)) I'd prefer a *real* Prolog.
Look, whenever I mention to anyone that I'm using Turbo-Prolog, I get
snickers and a reply just like yours. No one ever gives any real
evidence as to WHY Turbo-Prolog is not "real" Prolog.
I'm using Turbo for my homework projects in a compiler class; I find
it's environment far far more pleasant than using C-Prolog on an
overloaded VAX. I'm writing a compiler, and so far my difficulties
are about 80% with the Prolog language itself and 20% with differences
between Turbo and standard Prolog.
The major difference between Turbo and regular Prolog:
* No user-definable operators
* No grammar-rules (but this is just a syntactic transformation)
* Type-checking
Most of the abuse Turbo gets is based on the last one. It puts me in
mind of Fortran or C hackers looking at Pascal and saying "oh, gross,
you have to *declare* variables and *keep track of types*". The
type-checking doesn't seem to limit the power of the language, and
there are good things to be said for spelling out your data-structures
at the beginning of the program.
So please ... can someone who has honestly sat down and USED Turbo-Prolog
tell me precisely why it's not really Prolog at all. I've been using it
for a while now and it looks just like Prolog to me ...
--Peter Alfke
------------------------------
Date: 8 Mar 87 08:19:30 GMT
From: Mike Newton <newton@csvax.caltech.edu>
Subject: How do you like Turbo-Prolog? - (nf)
[This is a review of Turbo Prolog sent out in response to Peter
Alfke's recent comments on net.lang.prolog. The review was originally
sent to the AI-DIGEST many months ago, but I believe that
net.lang.prolog would also be a good place for it!]
[Also, in response to Peter's comments about the speed of the VAX --
C-Prolog runs on all of our SUNS, at (*real*) speeds (see notes below)
that are much better than Turbo's]
[ Caveats to remember when reading this review: I have *not* read all
of the manual, nor used it on many programs. Views expressed are from
the perspective of someone who has done the code generation and
evaluatable predicates for a high speed (~900 KLips on one processor
of a IBM 3090) prolog compiler. I have no affiliation with Borland,
and only a (*very*) indirect affiliation with IBM -- MON]
From a local software store we purchased Turbo Prolog over the weekend.
It came as a cellophane wrapped book with a couple of floppies. It cost
$69.95, list of $99.
The enviromnent was very nice. There was a window for the editor, goals
debugging information and messages. This seemed well done, and responded
reasonably well (I am not used to IBM-PC's.)
The unfortunate part was the Pascal-ization of the language. Everything
had to be typed (they called it domains). As far as I could tell, lists
had to be composed soley of other lists or elements all of one type. One
had to define the possible terms (giving the functor) that could be
arguments to a predicate. It seemed impossible to write generic predicates
for dealing with arbitrary types of terms.
Ex: to have a term that could be a 'symbol' (atom) or an integer
one had to do this:
domains
aori = a(atom) or i(integer)
It was not possible to just use an atom or an integer as a subterm...
Typing each subterm of a term is not my idea of Prolog.
After about an hour we got the 'standard' timing example of naive
reverse running (Some people have used other, non-environment-creating
samples. This is an unfair comparison). It did 496 unifications in
aproximately 11/100 of a second. This amounts to a speed of a little
under 5 Klips. Considering that they do not need to do 'real'
unification (since everything is pre-typed, and thus can be reduced to
a simple test), this speed is not particularly impressive.
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 as in
p(X,X).
?- p(X,Y), p(X,a).
And, it is not possible to assert clauses with variables.
In summary, I would say that there advertising is at best a
misrepresentation. They are not selling a 'Prolog' system! (If I
owned a TM on the word 'Prolog', I would be tempted to sue them!)
-- Mike
------------------------------
Date: Fri, 6 Mar 87 14:13:26 EST
From: Tim Finin <tim@linc.cis.upenn.edu>
Subject: Updating Databases With Incomplete Information
COLLOQUIUM
Computer and Information Science
University of Pennsylvania
UPDATING DATABASES WITH INCOMPLETE INFORMATION
Marianne Winslett
Stanford University Computer Science Department
Suppose one wishes to construct, use, and maintain a database of facts
about the real world, even though the state of that world is only
partially known. In the artificial intelligence domain, this problem
arises when an agent has a base set of beliefs that reflect partial
knowledge about the world, and then tries to incorporate new, possibly
contradictory knowledge into this set of beliefs. In the database
domain, one facet of this situation is the well-known null values
problem. We choose to represent such a database as a logical theory,
and view the models of the theory as representing possible states of
the world that are consistent with all known information.
How can new information be incorporated into the database? For
example, given the new information that ``b or c is true,'' how can
one get rid of all outdated information about b and c, add the new
information, and yet in the process not disturb any other information
in the database? In current-day database management systems, the
difficult and tedious burden of determining exactly what to add and
remove from the database is placed on the user. The goal of our
research was to relieve users of that burden, by equipping the
database management system with update algorithms that can
automatically determine what to add and remove from the database.
Under our approach, new information about the state of the world is
input to the database management system as a well-formed formula that
the state of the world is now known to satisfy. We have constructed
database update algorithms to interpret this update formula and
incorporate the new information represented by the formula into the
database without further assistance from the user. In this talk we
will show how to embed the incomplete database and the incoming
information in the language of mathematical logic, explain the
semantics of our update operators, and discuss the algorithms that
implement these operators.
------------------------------
End of PROLOG Digest
********************