mark@adler.philosophie.uni-stuttgart.de (Mark Johnson) (06/19/91)
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
brady@swift.cs.tcd.ie (06/20/91)
> 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 Hmm, I've been developing an Edinburgh-like Prolog for the Mac for the last little while, and I'll admit that Mark has a point. For me, the main problem is the lack of a good interface _paradigm_. The style that I've seen that I'm most comfortable with is used in Apple's MPW, which (in my view) integrates mouses & windows etc. in a _programmer_ friendly way. It doesn;t handle graphics at all. Apart from MPW I haven't seen a professional programming environment that I'd leave home for. I really dislike a system with lots of bitty windows all over the place, & I've tried to avoid it. On a particular point, an 'external' (i.e. add-on) predicate in Open Prolog allows some graphics and supports cut-and-paste to other Mac applications. I'm still looking for a nicer debugging system than the standard 4-port one. Any civilised debugger should have access to the source code. Obviously, there are some problems with that in Prolog, but they aren't insurmountable, given a little time... One other important point for me is that I've been concentrating on things like garbage collection and indexing because I want to run long/big programs. A compiler that I run on it garbage collects 40 MB on a particular run. A simulated-annealing program can garbage collect many 10s of megabytes (even with clause indexing, etc. to reduce memory requirements). Another area is connecting up Prolog programs with other systems, like databases, sound systems, and so on. These are a little more important for me. BTW, it should be obvious that what drives me is interest, not profit. No doubt my system has bugs in it, but user feedback would improve matters there. So, for the moment, user interface development on Open Prolog will take a back seat.
ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (06/20/91)
In article <1991Jun19.221421.7975@swift.cs.tcd.ie>, brady@swift.cs.tcd.ie writes: > I'm still looking for a nicer debugging system than > the standard 4-port one. Any civilised debugger should have access to the > source code. Obviously, there are some problems with that in Prolog, but they > aren't insurmountable, given a little time... What exactly is it you don't like about the 4-port debugger? (There are other models around; the 5-port debugger, AORTA, BIM's one.) Source code access is an entirely orthogonal issue. Running QP under (UniPress or GNU) Emacs, at any of the four ports you can type a dot "." and there you are at the source code. All you have to do is keep track of where things come from (see `source_file' in the Quintus manuals). Have you see LPA Prolog for the Mac? Navigating around the source code on that system seems rather pleasant. > No doubt my system has bugs in it, but user feedback would improve matters > there. Hint. -- I agree with Jim Giles about many of the deficiencies of present UNIX.