🚀 go-pugleaf

        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   bimbart@kulcs   bart@sunbim