PROLOG-REQUEST@SUSHI.STANFORD.EDU (Chuck Restivo, The Moderator) (05/18/87)
PROLOG Digest Monday, 18 May 1987 Volume 5 : Issue 38
Today's Topics:
Pragmatics - Standardisation,
Implementation - Side Effects & BIM
----------------------------------------------------------------------
Date: Tue, 12 May 87 10:20:40 BST
From: William Clocksin <wfc%computer-lab@Cs.Ucl.AC.UK>
Subject: Standardisation
A note on this appeared some months ago. The British Standards
Institute has a group working on this. The main committee meets
quarterly. There are formal links with AFNOR, ISO, and ANSI;
a number of people in the Prolog community are involved and
are sent the papers. Any suggestions/ideas/opinions that are
aired in the Prolog Digest will automatically come to the attention
of the committee. The standardisation process operates by
consensus; this takes several years, and we are about halfway
through.
------------------------------
Date: 8 May 87 14:21:09 GMT
From: Gerda Janssens <mcvax!prlb2!kulcs!gerda@seismo.css.gov>
Subject: side-effects
The efficient update problem is also addressed by our group at Leuven
where abstract interpretation is used to detect garbage at compile
time. Often the detected garbage can be reused, the net effect being
the same as with destructive assignments.
Papers on the subject will appear in Proc. IFIPWC2.1. Working
Conference on Program Specification and Transformation (Bad-Tolz April
86) and in Proc. 1987 Symposium on Logic Programming.
-- M. Bruynooghe and G. Janssens
------------------------------
Date: Sun, 17 May 87 14:47:50 PDT
From: Mike Newton <newton@vlsi.caltech.edu>
Subject: BIM review
This is a copy (slightly edited) of a letter I recently sent
to BIM. I have no connection with them other than possibly being a
customer in the near future. I thought that the people on the list
may be interested in this review:
Dear People,
Recently we were sent a demonstration copy of BIM prolog by
Bert Shure. This letter represents my experience using this product a
couple of hours a day, over the last few days. We were running on a
Sun-3/160 using SunOS 3.0.
Overall the product seemed very nice. The compiler produced
fast code and the interpreter also ran fast. The interpreter and
compiler interacted well, there was a DEC-20 syntax compatibility
mode, and most of the normal evaluateable predicates existed. However
we have decided not to buy it quite yet due to a few problems mentioned
below.
My first comments regard the installation and demonstration
scripts. I did not spend a lot of time trying to fix the scripts, as
it was easier to do the correct things manually. However the fact
that they were broken was mildly annoying. It is also not a fair
assumption that people installing BIM prolog will want to have a
separate UID (user) for this program.
The most serious deficiencies could roughly be described as
`robustness' issues. These directly interfere with the ability to use
BIM prolog successfully:
- Dumped core frequently -- Error recover was almost
non-existant. This was probably just a result of running large
programs. Often this came with a message of the form ``sindsig: bad
user stack, pid=1751, sig=11'' and ``usp is ef81fdc action is e6f10,
upc 2b872'' appearing on the console.
- Stack protection -- most of the time that it dumped core
seemed to be the result of stack overflow. There should be a compiler
switch to put a stack test at the beginning of each predicate -- this
is easy, as one can compute the maximum amount of each stack produced
by each procedure at compilation time. A corresponding run time flag
should be used for clauses that are added to the program though
asserts.
- Neither compilation with the ``occurs'' flag, nor use of
occurs/2 actually guaranteed that a circular term was not being
created.
- There was no way (I could tell) of a program finding out the
current usage in the various stacks. (This seriously aggravated the
stack overflow problem). (please(statistics) reported the statistics
out to the user).
In addition to the above problem, BIM prolog lacks a few minor
features (roughly in order of importance):
- The debug printer should recognize recursive terms, and
print them accordingly.
- A description of the format of the WAM code in the
intermediate files.
- A description of the format of terms in memory -- useful if
one can pass a pointer to a term to a C program. I do not mind having
to do horrible things in C as long as I CAN do them. Even if I can
not modify terms, I still may still want to look at them from C code.
- Online documentation -- I often dial in to the machine at
work. Though the documentation does not have to be part of the system
(like Quintus), it should still be on line in some format.
On the other hand, there were numerous features that were useful:
- Not only was the compiler fast (about 125KLips), but the
interpreter was fast too (about 4KLips -- both measurements on a
SUN-3/160). The speed of asserts was ok -- about 25 ``complicated''
(70 characters/clause, two characters/atom, one character/var) clauses
a second.
- The suncore/sunwindows support.
- The (almost complete) foreign language interface, along with
some samples.
- Very nice debugging options.
In summary, we were impressed with the product, but are still
debating whether or not to buy it. If some of the above problems were
addressed, we would almost certainly buy it.
A final question: Will there be support of ``x-windows'' in a
future release?
Sincerely,
Michael O. Newton
------------------------------
End of PROLOG Digest
********************