PROLOG-REQUEST@SUSHI.STANFORD.EDU.UUCP (05/28/87)
PROLOG Digest Friday, 29 May 1987 Volume 5 : Issue 40
Today's Topics:
Query - Sun,
Implementation - BIM
----------------------------------------------------------------------
Date: 14 May 87 13:02:00 GMT
From: necntc!adelie!mirror!ishmael!inmet!dwyer@ames.arpa
Subject: prolog for sun
I am interested in prolog implementations for the SUN 3. This
implementation would be used for educational and research purposes
only. I have a copy of UNSW prolog running on a vax but am having
trouble porting it to the SUN.
Any information regarding such implementations (or help with the port)
would be greatly appreciated.
-- matt dwyer
------------------------------
Date: 20 May 87 09:11:31 GMT
From: Bart Demoen <mcvax!prlb2!kulcs!bimbart@seismo.css.gov>
Subject: Mike Newton's review of BIMprolog
This is the main contents - not a copy - of a letter we
recently sent to Mike Newton. We have no connection with him other
than him possibly being a customer in the near future. We thought
that the people on the list may be interested in our comments on his
review of BIMprolog:
The complaint about the robustness - the core dumped and the bad user
stack message on the console - is due only to the fact that Mike's
programs construct and manipulate - write for example - circular
terms; even without seeing his programs we know this because
1. we have never had this message except when manipulating circular terms
2. Mike's first 3 complaints show this as does the first minor feature Mike
claim BIMprolog misses: 'The debug printer should recognize
recursive terms, and print them accordingly'
By the way, it is not a prolog stack which overflows, it is the
C-stack. Your second complaint shows that you think BIMprolog has no
(prolog)stack overflow tests: this is completely wrong; at every call,
heap and stack-trail tests are performed - as in every decent prolog
system; speed would increase with at least 20% if we wouldn't !
We agree that our occur check option is not safe, we should indeed
remove it from the manual until it is - we are working on that.
Circular terms, if carefully handled, do not produce this user stack
overflow - we use circular terms for instance to represent a graph,
but we must write our own write-routines for the graph of course.
please/1 gives you the possibility to inspect the size of the stacks -
and of other data spaces ( ?- please('read manual') . ) please/1 gives
you the possibility to limit the depth with which a term is written
out
I am really angry about the publishing of reviews like Mike's, in a
Digest, not because it could show weak points of a product. Rather
because nobody benifits from a too short evaluation by a non-expert.
This letter is my personal initiative, not approved by the company BIM.
Sincerely,
-- Bart Demoen
------------------------------
Date: Sun, 24 May 87 02:46:11 PDT
From: Mike Newton <newton@vlsi.caltech.edu>
Subject: regarding the response to the BIM review ...
Dear people:
This is a response to Bart Demoen's note.
I have posted reviews of Turbo Prolog and BIM prolog. I gave
a rather negative review of Turbo Prolog and a rather positive (I
thought) review of BIM prolog. In both cases I got rather ``flamed''.
In the later case, I got flames from the author, even though the
review generated (in only a couple of days) two rather positive
inquiries for more information about BIM.
In the following discussion, please note that I assume the
following: IT IS MUCH MORE IMPORTANT TO POINT OUT ALL FAILINGS OF A
PRODUCT TO LIVE UP TO A STANDARD, THAN IT IS TO GO THROUGH A LONG
CHECK LIST SAYING THE PRODUCT MET EACH AND EVERYONE OF 999 ITEMS.
This would be nothing more than the language manual, and I could well
see why BIM's competitors would scream fowl if the BIM manual was
posted to the net.
In reverse order from Bart's note.
>> This letter is my personal initiative, not approved by the company BIM.
This may be true, but the BIM manual lists you as the principal author of the
manual and one of the writers of BIM prolog
>> I am really angry about the publishing of reviews like Mike's, in a
>> Digest, not because it could show weak points of a product. Rather
>> because nobody benifits from a too short evaluation by a non-expert.
If there were either positive points (new features) or negative
points (bugs, inconsistencies), that is what SHOULD go in a review.
``... too short [an] evaluation by a non-expert'' seems to be
a swipe at my Prolog skills. I may not be an ``expert'', but here are
some qualifications:
[a] A thesis dealing with extensions to the WAM for a functional
(conservative and efficient!) extension to Prolog.
[b] Author of the code generator and most of the evaluatable
predicates for a Prolog compiler that runs at close to one
million LIPS.
[c] Consulting experience writing compilers in Prolog
>> The complaint about the robustness - the core dumped and the bad
>> user stack message on the console - is due only to the fact that
>> Mike's programs construct and manipulate - write for example -
>> circular terms; even without seeing his programs we know this because
>> 1. we have never had this message except when manipulating circular
>> terms
>> 2. Mike's first 3 complaints show this as does the first minor
>> feature Mike claim BIMprolog misses: 'The debug printer should
>> recognize recursive terms, and print them accordingly'
>> By the way, it is not a prolog stack which overflows, it is the
>> C-stack.
>> We agree that our occur check option is not safe, we should indeed
>> remove it from the manual until it is - we are working on that.
When the manual says '-o' will ``turn [on] the occurcheck'' I
expected it to work.
>> Your second complaint shows that you think BIMprolog has no (prolog)stack
>> overflow tests: this is completely wrong; at every call, heap and stack-
>> trail tests are performed - as in every decent prolog system; speed would
>> increase with at least 20% if we wouldn't !
(Actually, on some virtual memory systems this isnt true. The
compiler we wrote detects stack overflows without using stack tests.
It then lets the current WAM instruction finish and then calls the
garbage collector. This would probably not be possible on the Suns
under release 3.2.)
I did think the tests were missing, and am glad they are not. My
apologies.
>> please/1 gives you the possibility to inspect the size of the stacks - and
>> of other data spaces ( ?- please('read manual') . )
>> please/1 gives you the possibility to limit the depth with which a term is
>> written out
I did read the manual -- several times. For example, did you
know that '=:=' '\=' are in the manual, but not in the index although
most of the other special predicates are?
please/1 does give the ability to set the depth -- and the
manual also states that ``-rn When printing out a structured term,
ther term is only considered to a depth of n. ... A negative number is
read as infinity'' but the command line argument passing gets screwed
up if you say -r10. It is also very disconcerting not to be able to
test current stack size from within a program.
Developers should not let criticism of a few points cause them to
get mad so easily. Especially when the overall the review was favorable.
Snide comments about the reviewer alienate not only the viewer, but
the audience as well.
I have been trying out all the Prolog's that I can. As I
mentioned in the previous letter, I was overall impressed with BIM.
If _I_ had to choose one prolog to run on Sun's now, _I_ would pick
it. HOWEVER, there are two Prolog's that I have yet to try
(Nu-Prolog, and another by a company that has yet to `announce' their
version). A large part of my choice is based on speed -- other
prolog's may have a nicer environement, others may have fancy bells
and whistles. I tend to do 1-100 hour runs and use large amounts of
memory, so as much as I like C-Prolog, it is time for a faster Prolog
-- with a garbage collector!
- mike
------------------------------
End of PROLOG Digest
********************