Newsgroups: comp.lang.prolog
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!pipex!uunet!allegra!alice!pereira
From: pereira@alta.research.att.com (Fernando Pereira)
Subject: Re: Death to Arity!
In-Reply-To: serge@cs.sfu.ca's message of 12 Dec 1994 18:02:02 GMT
Message-ID: <PEREIRA.94Dec12211431@alta.research.att.com>
Sender: usenet@research.att.com (netnews <9149-80593> 0112740)
Nntp-Posting-Host: alta.research.att.com
Reply-To: pereira@research.att.com
Organization: AT&T Bell Laboratories
References: <1994Dec5.215606.15801@bnlux1.bnl.gov> <3c0qom$eb4@hobbes.cc.uga.edu>
	<TOM.94Dec9150953@heather.kwi.com>
	<SERGE.94Dec12100202@maroilles.cs.sfu.ca>
Date: Tue, 13 Dec 1994 02:14:31 GMT
Lines: 48

In article <SERGE.94Dec12100202@maroilles.cs.sfu.ca> serge@cs.sfu.ca (Serge Le Huitouze) writes:
   In article <TOM.94Dec9150953@heather.kwi.com> tom@kwi.com (Tom Howland) writes:

      I really hate Arity Prolog. Some of the reasons include

   ...stuff deleted

      ** doesn't have dynamic stack expansion, nor does it have a garbage
      collector. For example, a seasoned Arity Prolog programmer would *never*
      call sort/2 -- he's afraid of running out of stack space! Here is a
      typical atrocity I came across


   I totally agree that it a shame not to have a garbage collector in a Prolog
   system.

   I also totally disagree with your statement that lack of dynamic stack
   expansion is a pain.
   I remember having used Quintus compiled code about 10 years ago. At that time,
   Quintus was undoubtly the fastest Prolog system. I think it had no garbage
   collector (or a very poor one, a la Lisp ?) but had a dynamic expansion
   policy. The clear consequence of that was that Quintus was the fastest Prolog
   to crash a Unix system (moreover, it was sometimes necessary to reboot the
   machine because of a bug in the Unix OS, but that's another point !)
I've lost track of which version of Quintus Prolog was which (it is 10
years since then, after all), but I had something to do with the stack
expansion code in some of the early versions, as I had with the first
Prolog with stack expansion, DEC-10 Prolog. In both systems (except
possibly in QP 1.0), the user could limit the amount of memory space
available for stack growth. The stack expander tried to allocate the
existing space to the best of its ability by shuffling space between
the various stack areas, until there was *no* space for any growth, at
which time a stack overflow error was signaled and the execution
aborted to the top level read-execute loop. Therefore, the user could
avoid running out of swap space on a runaway Prolog execution by
specifying a conservative memory limit. This was well documented.

As for crashing the OS, you should lay that problem at the door or
certain incompetently designed virtual memory systems (no names
named). Unfortunately, relatively little has changed since then...


--
Fernando Pereira
2D-447, AT&T Bell Laboratories
600 Mountain Ave, PO Box 636
Murray Hill, NJ 07974-0636
pereira@research.att.com
