restivo@POLYA.STANFORD.EDU (Chuck Restivo) (07/12/88)
Date: Mon, 11 Jul 1988 02:53-PST
From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU>
Reply-to: PROLOG@POLYA.STANFORD.EDU>
US-Mail: P.O. Box 4584, Stanford CA 94305
Subject: PROLOG Digest V6 #44
To: PROLOG@POLYA.STANFORD.EDU
PROLOG Digest Monday, 11 July 1988 Volume 6 : Issue 44
Today's Topics:
Query - dBase III,
Implementation - VAX/VMS Review
------------------------------------------------------------------------------------------------------------------------------
Date: 24 Jun 88 18:29:32 GMT
From: uccba!ucqais!bbeck@tut.cis.ohio-state.edu (Bryan Beck)
Subject: Query Dbase III Plus with Turbo Prolog
I recently read an article in AI EXPERT, June 1988 written by Karl Horak about
using Turbo Prolog to query Dbase III Plus files. There were two points that
were not clearly delineated in the article, (1) How to get prolog to read the .dbf and
how to get prolog to read the .dbt files.
Also the article referencing Fileman, Rick. "Memo to Character Conversion,"
Aston-Tate Inc. TechNotes, Nov. 1987,pp 15-24.
I any one has read this article of have done anything like this, or where I can find these TechNotes. I would greatly appreciate any additional information
about trying to do this.
Thank you.
------------------------------
Date: 29 Jun 88 14:37:22 GMT
From: mcvax!ukc!dcl-cs!simon@uunet.uu.net (Simon Brooke)
Subject: Survey of Prologs for VMS VAX
About 10 days ago, I put out a message asking people to recommend PROLOGs
for VAX VMS. Many thanks to all those who replied. I'm posting (in case
anyone else is interested) what I learned. Brief word of explanation: I
was asked to select a PROLOG in which it would be possible to construct an
interface to a relational database mangement system, and the report is
heavily biased to reflect this need.
PROLOGs available for VAX/VMS:
A brief review, with regard to the needs of the Savant
project.
How systems were selected for inclusion into this report
In order to find as many VMS compatible PROLOGs as
possible, in the shortest possible time, I posted to the
USENET newsgroup comp.lang.prolog, on the basis that all
serious PROLOG developers would inevitably keep an eye on
this. This method appears to have was only partially
partially successful, in that it produced reviews of most
of the systems I was already aware of, including systems I
wasn't aware were available for VMS. However, it didn't
produce any news of systems I don't know about, and there
may still be some of those.
I also consulted the news section of the Journal 'Expert
Systems', going back two years.
What I asked for
The message which I posted asked respondents to tell me:
* What syntax it uses - especially, how like Quintus it is.
* What the 'foreign function interface' is like.
* Roughly what the performance is like.
* What the programmer's environment is like . . .
* How robust it is - and any points to watch...
* What it costs and from whom (UK supplier if possible)
The systems included
The systems which I received replies about were as follows
(in the order I received them):
Edinburgh Prolog
Quintus Prolog (two replies)
BIM_Prolog (two replies)
Poplog
On the whole, replies were directly from implementors, and,
although they may be somewhat more honest than promotional
literature, cannot be considered independent.
I also have received promotional material describing
LPA Sigma Prolog
and have found a news item describing
I/F Prolog.
Experience of the systems
I have been able to play with Quintus (on Suns under Unix),
Edinburgh (on VAX under Unix), and Poplog (on Suns under
Unix).
Quintus
This is the only one of the systems I have any significant
experience with. Quintus is a widely used - and in general
widely liked - version of a vanilla flavoured Edinburgh-
syntax PROLOG. After LISP machines, the EMACS based
development environment strikes me as so wretchedly crude
as to be almost unusable. However, by using system editors,
code can be developed reasonably quickly.
The system is relatively fast, and appears well thought out
and solid. I imagine that, on a Xerox workstation, this is
a very nice system.
Edinburgh
I have played only briefly with Edinburgh Prolog. I loaded
in the dBAccess code, most of which ran. However, the use
of the token 'not' as a negation operator is apparently not
permissible in Edinburgh prolog, and, as I did not have a
manual, I was unable to attempt to patch this.
There appears to be no compiler.
My feeling, however, is that it would be trivial to port to
Edinburgh Prolog. Whether any particular development
environment tools are supplied I can't say; but if not,
they aren't strictly needed.
Poplog
Again, I have experimented only briefly with Poplog. My
first impression was of quite remarkable slowness. Whilst
the reader of the Edinburgh system skipped over the
declarations in the (Quintus) files containing the dBAccess
code which it could not understand (because they were
Quintus specific), the Poplog reader aborted. Thus these
files could not be loaded without some editing.
Again, the syntax of 'not' differed from Quintus; in Poplog
prolog, 'not' is a one place predicate rather than a prefix
operator.
Once the files had been edited, they loaded satisfactorily,
and again, very nearly ran. Again, there appeared to be no
compiler.
Discussion
Relative performance
I don't have any good comparative figures on the relative
performance of these systems. However, what I have is as
follows:
Version KLips Hardware KLips Test Syntax Price
/Mips
Edin 2.2 VAX 750/Unix 3.66 N.Rev Edinburgh #1000
BIM 26 VAX 750/VMS 43.33 N.Rev proprietary #8150
85 Sun 3 42.5 ?? [Edin optional]
Sigma 6.9 Sun 3 3.45 ?? Lisp-based #750 [one user]
[Edin optional]
Quintus 60 Sun 3 30 N.Rev Edinburgh #4200
I/F 90 Sun 3 45 ?? Unknown #11000
40 VAX 780 ?? ??
Poplog 4.5 VAX 750 7.5 ?? Edinburgh #12000
As the Sun is rated at about 2 Mips, and the VAX 750 at
0.6 Mips, this suggests that I/F may be fastest of all,
with LPA Sigma slowest; the column KLips/Mips uses this
estimation to try to produce a normalised speed for each
implementation. Also, these figures come from various
different sources, and reflect different peoples
benchmarks; they may not be directly comparable.
Nevertheless, the fastest PROLOGs are clearly very much
faster than the slowest. This at least partly reflects the
fact that some of these systems are interpreters only,
while some have compilers. Certainly Sigma has no compiler,
and I was unable to find one in either the Edinburgh or
Poplog systems. Given the benchmark speeds quoted, I would
suspect that none of these systems has a compiler, while I
know that all the others do.
Prices and where possible speeds have been verified with UK
suppliers.
Foreign Function Interface
All the systems described with the exception of I/F (about
interfaces to C. Specific claims are as follows:
Edinburgh
"Users can supply C bodies for Prolog predicates - this is
easy under UNIX, as the .o file can be dynamically loaded,
but we are just now doing the decomposition to let the
object file be linked into the executable under VMS (pardon
any terminology errors, VMS isn't my own field)" (source:
Correspondence with implementor)
BIM:
"BIM_Prolog has a complete interface to all procedural
languages which create a standard VAX/VMS object file.
Examples of C and Fortran are delivered with the
distribution" (source: Correspondence from BIM
representative)
"BIM_Prolog has an external language interface, although it
has no dynamic linking: it means that you can link into the
system a package (or more than one) with C functions - or
assembler, pascal, ada ... as long as the linker of VMS can
link the object of BIM_Prolog to it" (source:
correspondence with user)
LPA Sigma:
"A simple to use 'C' language interface allows new
facilities to be added quickly to the basic system"
(source: promotional literature).
Quintus:
The UNIX version of Quintus provides interfaces to C,
Pascal, and Fortran; I have no information to hand about
the VMS version. (source: User Guide)
I/F: no information
Poplog:
The Poplog environment includes LISP, POP-11, and
optionally ML in addition to Prolog, and all these can be
integrated. Additionally, "....you can link in C, Fortran,
or whatever" (source: correspondence from Prof Aaron
Sloman)
Recommendations
I would not at this stage recommend I/F Prolog, as,
although it's performance is reported to be very good, I
don't have adequate information about it; also, it's price
is extremely high. I would not recommend Sigma, as its
performance is just too poor, and this generally reflects
my experience of LPA implementations - nice systems with
dreadful performance. Also, LPA are no longer supporting
Sigma. They plan to have a new implementation out sometime
next year. Of the remaining systems:
Quintus
Quintus is (I believe) the market leader; it is solid, well
behaved and well supported, reasonably fast and not
excessively priced.
BIM
BIM_Prolog has two primary advantages: firstly it is fast;
secondly, it comes with a complete and working database
interface. Although it is more expensive than Quintus, the
benefits of a supplier supported db interface might well
more than make up for this from Savant's point of view (of
course, it would also put me out of a job).
Poplog
Is a very rich environment - far richer than is needed for
the current project. Although a nice product, it is less
suitable for our purposes than BIM, in view of its greatly
inferior speed, and lack of database interface.
Edinburgh
Is adequate for development purposes, and is very cheap.
The project would probably have to buy a faster system when
the time came to construct a marketable product.
Conclusion
Edinburgh PROLOG, plus my salary for as long as it takes to
make Edinburgh do what BIM already does, would probably add
up to a fair proportion of the cost of BIM - for a system
with markedly inferior performance.
So I (were I not me) would buy BIM (I'd want to see it first) - unless a
proprietary database interface is of primary importance; in
which case Edinburgh would do only as a cheap development
system, with Quintus being required for serious product
development.
-- Simon Brooke
--------------------------------
End of PROLOG Digest