Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!sdd.hp.com!swrinde!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!rusmv1!rusmv1!mark From: mark@adler.philosophie.uni-stuttgart.de (Mark Johnson) Newsgroups: comp.lang.prolog Subject: Poor state of Mac Prologs (was "Unbinding" in Prolog) Message-ID: Date: 19 Jun 91 16:14:14 GMT References: <421@daily-planet.concordia.ca> <6379@goanna.cs.rmit.oz.au> Sender: news@rusmv1.rus.uni-stuttgart.de (USENET News System) Organization: IMSV, University of Stuttgart, Germany Lines: 62 In-Reply-To: ok@goanna.cs.rmit.oz.au's message of 18 Jun 91 10:41:45 GMT For what it's worth, as far as I know BNR Prolog doesn't do last-call optimization and doesn't garbage collect. It was designed with failure-driven loop style programming in mind, and data-base operations are supposed to be reasonably efficient. (Perhaps Andre' Vellino can set me straight if I'm wrong here). Despite these drawbacks I find it a very useful little system. I especially like the fact that it has freeze, and that I can copy graphics I create with it into Word documents in the standard Mac fashion. When I give it around 8 Mb of memory the lack of last call optimization and garbage collection doesn't seem so serious, at least for the smallish programs I usually write. In general, I am very disappointed with the Prologs available for the Mac. I have four or five Prologs for the Mac, and they are all poor, in my mind. Doing a decent job on a Mac interface seems to be beyond most Mac prolog implementors capabilities. I strongly recommend that any Mac prolog implementor study the way that the user interaction in Apple MacIntosh Lisp (MCL) (or when running Prolog as a subprocess under Epsilon on a PC) is organized: e.g. you need to keep track of *two* points in the Listener window, (where the user's cursor is currently located, and where the Prolog interpreter is currently reading from and writing to). But all Mac prologs I know of only use one point, with the result that user interaction is just a mess. I think anybody implementing a prolog on the Mac should be forced to sit down and study MCL; these guys have figured out how to implement a user interface that is an order of magnitude better than any Mac prolog I have seen, and there is no reason to reinvent the wheel. But I'm afraid that the fact that MCL is a Lisp implementation is enough to put off most prolog implementors - so smug are they in their monolingual viewpoint. Second, just about all Mac prolog implementors seem to feel the need to "improve" on the Edinburgh standard in some incompatible way. These "improvements" usually suffice to break most standard programs. Sorry for the strong remarks, but I'm sick and tired of all these half-baked prologs for the Mac. This is one case where I would truly like to be shown to be wrong... Mark -- Mark Johnson Institut fuer maschinelle Sprachverarbeitung - Computerlinguistik Universitaet Stuttgart Keplerstrasse 17 D-7000 Stuttgart 1 West Germany. (you need "West" otherwise mail from the US is not delivered!) work phone: 0711 - 121 3132. On leave until mid July 1991 from: Cognitive and Linguistic Sciences, Box 1978 Brown University Providence, RI 02912 USA email addresses: mark@adler.philosophie.uni-stuttgart.de mj@cs.brown.edu