restivo@POLYA.STANFORD.EDU (Chuck Restivo) (07/10/88)
Date: Sun 10 July 1988 02:53-PST From: Chuck Restivo (The Moderator) <PROLOG-REQUEST@POLYA.STANFORD.EDU> Reply-to: PROLOG@POLYA.STANFORD.EDU> US-Mail: P.O. Box 4584, Stanford CA 94305 Subject: PROLOG Digest V6 #41 To: PROLOG@POLYA.STANFORD.EDU PROLOG Digest Sunday, 10 July 1988 Volume 6 : Issue 41 Today's Topics: Query - Reference Guide, Familiar Debate - Procedural v. Non-Procedural, Implementation - GNU v. Unipress ---------------------------------------------------------------------------------------------------------------------------- Date: 20 Jun 88 17:54:42 GMT From: bgsuvax!maner@tut.cis.ohio-state.edu (Walter Maner) Subject: NEED PROLOG QUICK REFERENCE GUIDE I am trying to compress essential information for first-time Prolog users into a single sheet of paper (back and front). Any suggestions about what should go there? Any pointers to existing quick-reference sheets? ------------------------------ Date: 20 Jun 88 22:32:45 GMT From: debray@arizona.edu (Saumya Debray) Subject: NEED PROLOG QUICK REFERENCE GUIDE "Variables of the world, unify!" -- Saumya Debray ------------------------------ Date: 30 May 88 04:03:14 GMT From: quintus!ok@unix.sri.com (Richard A. O'Keefe) Subject: Prolog Is Semi-Procedural In article <5500005@uiucdcsm>, mccaugh@uiucdcsm.cs.uiuc.edu writes: > I submit that "prolog" - the so-called "logic-programming" language - is > (among other disclaimers) NOT altogether the "declarative" non-procedural > language it is advertised to be. Case in point: > sum(0,0). > sum(N,M) :- N1 = N-1, sum(N1,M1), M = M1+N. > In a truly non-procedural (i.e. (I anticipate controversy here) non- > deterministic) language, the test: N>0 should not be necessary, and yet > (as we know), it must appear to avoid stack-overflow (in CPROLOG, UNSW- > PROLOG, anyway). The conclusion is valid, but the argument is bogus. {What's with this N1 = N-1 business, anyway? In C Prolog the code as written will never succeed for any first argument other than 0. E.g. sum(1, X) -> sum(1-1, M1) -> sum(1-1-1, M1') -> sum(1-1-1-1, M1") -> ...} Claim: there is no "declarative" language permitting recursive declarations currently existing in which control issues can be ignored. (Lazy ML, Miranda, even the relational algebra, support this claim.) While in this case it is straightforward to show that for sum/2 to succeed its first argument must be a non-negative integer, in general it is at least as hard as solving the halting problem (insert standard trivial proof here). "Non-procedural" and "non-deterministic" are orthogonal concepts. E.g. ICON is non-deterministic but non-procedural, ML is non-procedural but not non-deterministic, Pascal is neither. ------------------------------ Date: 31 May 88 11:08:40 GMT From: mcvax!ukc!warwick!expya!exsb.cs.exeter.ac.uk!jtr@uunet.uu.net (Jason Trenouth) Subject: GNU vrs UNIPRESS Walter Maner writes: > We have the happy dilemma of deciding whether to use the excellent Unipress > EMACS which come bundled with Quintus Prolog or integrating the GNU EMACS, > already installed, with Quintus Prolog. Any observations of experiences > would be welcome. I suppose our preference is to interface with GNU if that > is easily accomplished without loss of functionality. and Martin Carroll replies: >> GNU GNU GNU GNU GNU GNU GNU >> >> I hate unipress. I've been through five stages of editor with Quintus Prolog. Initially I used the UNIPRESS Emacs that QP came with. Gradually I discovered that this was not the same as the GNU Emacs that the rest of the department used. The differences were mostly little irritations, but they were all with UNIPRESS. For a short while I used GNU Emacs, but I became frustrated by the lack of a handy rodent. Then I turned to the SPY editor (UK mouse-based editor). However, its impossible to run a Prolog subprocess through it sensibly, and I moved on to the Sun's own "textedit". This had the added advantage of having the same interface as the "mailtool" and "cmdtool" (for those who know what I'm talking about). Then the department began using the Sun-interfaced GNU Emacs and my troubles were over. Yessiree, I'm a BORN AGAIN GNU lover. CONS: No compile option. Quintus Prolog doesn't get tricked into believing the buffer is the original file (i.e. multifile warnings if you switch between buffer consults and normal consults). No help file interface. Some unsupported libraries effected (e.g. big_text). No find definition power (Ouch this hurts!), and not linked to debugger. Not supported. PROS GNU Emacs has an all-round better feel than UNIPRESS. Better integrated with a Sun workstation (if you got one!). If GNU Emacs is already widely used within your organisation, then so much the better for the Prolog user who doesn't need to change his editor to read any mail etc. (OK UNIPRESS can do other things but see below.) To keep two comparably full versions of Emacs around is an enourmous waste of disk space! What could happen (i.e. happened here) is that it was only possible to use a stunted version of UNIPRESS Emacs - thus making GNU Emacs infinitely better in any feature comparison. I gather that GNU is more powerful anyway (unconfirmed). Certainly, some hardware manufacturers (e.g. Pyramid) started supplying GNU in addition to UNIPRESS because their user-base prefers it. The only feature that I wished for was "find-definition". GNU Emacs has a more general/powerful "find-tag" feature. However, it relies on an associated program called ETAGS which currently only understands C, FORTRAN, LISP, and LATEX (text formatter). Rather than waiting for Richard Stallman's (Ohmmme) merry men to correct this deficiency I recently wrote PTAGS. This creates a TAG FILE from a Prolog file(s) that GNU Emacs can use to implement "find-tag" for Prolog. PTAGS is written in Prolog (~10K) and is sort of available after I check with our system admin about the proper place to post it. "If the feel is against you then argue the features. If the features are against you then argue the feel. If they are both against you, call the other Emacs names." -------------------------------- Wed, 8 Jun 88 05:47:20 PDT Date: 7 Jun 88 07:21:28 GMT Subject: Re: GNU vrs UNIPRESS In article <500@expya.UUCP> jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) writes: >Walter Maner writes: >Then the department began using the Sun-interfaced GNU Emacs and my troubles >were over. Yessiree, I'm a BORN AGAIN GNU lover. There is a Prolog-mode for GNU Emacs that we got from Aerospace. I'll contrast it with Trenouth's points. > No compile option. Meta-k and Meta-i are there. > Quintus Prolog doesn't get tricked into believing the buffer is the > original file (i.e. multifile warnings if you switch between buffer > consults and normal consults). {don't know about this} > No help file interface. It's all there. > Some unsupported libraries effected (e.g. big_text). The \042(command)\041 escape method is handled, so this should work. > No find definition power (Ouch this hurts!), and not linked to > debugger. Find-definition is there. > Not supported. Ah, there is that. This package does a really thorough job of imitating the Emacs interface documented in the Quintus manuals. We'd like to distribute it. The trouble is, as it has always been, the GNU "copyleft". It looks as though it _may_ be safe for us to give out the occasional copy of _exactly_ what we were given, but the GNU terms can be interpreted as requiring us to give away all the Quintus Prolog sources if we ever distribute GNU Emacs code that *we* have changed. (The whole point of an editor interface like this is to produce the illusion of a single program, after all.) There are a lot of nice things you can say about GNU Emacs, but "it encourages companies to develop supported products based on it" is by Stallman's careful choice not one of them. ------------------------------ Date: 8 Jun 88 13:04:40 GMT From: bunny!bs30@husc6.harvard.edu (Bernard Silver) Subject: GNU vrs UNIPRESS In article <500@expya.UUCP> jtr@exsb.cs.exeter.ac.uk (Jason Trenouth) writes: >Then the department began using the Sun-interfaced GNU Emacs and my troubles >were over. Yessiree, I'm a BORN AGAIN GNU lover. > >CONS: > > > No find definition power (Ouch this hurts!), and not linked to > debugger. It is fairly easy to make a find_definition function for emacs. You have to load an extra predicate into your prolog code but thats OK. Note that find_pred(Pred,Arity) :- current_predicate(Pred,Skel), functor(Skel,Pred,Arity), !, source_file(Skel,FileName) <Stuff ommited here> locates the file that pred is in (if it exists). The rest of the definition writes out the relevant commands for gnu to find that file and search for the predicate. These commands are written in a temp file that GNU automatically loads when the find definition command is issued. It works fine. If current_predicate fails, a GNU error message is written to the temp file. Compiling regions does have the problem that you mentioned (that GNU believes it comes from a different file) but this really isn't too much of a hassle. ( I turn the error detection off automatically when compiling regions. If Prolog complains when I load in the file (predicate previously defined in user) I can safely ignore this) -- Bernard ------------------------------ Date: 13 Jun 88 14:53:56 GMT From: macbeth!dowding@burdvax.prc.unisys.com (John Dowding) Subject: GNU vrs UNIPRESS In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >*we* have changed. (The whole point of an editor interface like this is >to produce the illusion of a single program, after all.) There are a lot Although I would normally hate to nit-pick a (parenthetical) comment, I have to make an exception in this case. I dont think that you want the emacs interface to produce the illusion of a single program at all. In the name of this illusion, the Quintus Prolog emacs interface has the following "features": - You cannot start Prolog w/ interface if you are already in emacs. Prolog can only be called from the (in our case) unix prompt. - Many nice, handy emacs features have either been deformed or destroyed. These include delete-window (why *cant* I take the prolog buffer off the screen for a while. I know how to get it back), and shell (in our version, you couldnt run any other subprocess besides prolog, not even a clock). Besides this, because the prolog/emacs interface was a separate environment, Quintus felt free to make arbitrary changes to the default key bindings that had nothing to do with prolog. These include the kill-ring commands, and incremental search. -- John Dowding ------------------------------ Date: 14 Jun 88 04:53:25 GMT From: quintus!ok@unix.sri.com (Richard A. O'Keefe) Subject: GNU v. UNIPRESS In article <6604@burdvax.PRC.Unisys.COM> dowding@macbeth.PRC.Unisys.COM (John Dowding) writes: >In article <114@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: >>(The whole point of an editor interface like this is >>to produce the illusion of a single program, after all.) > >Although I would normally hate to nit-pick a (parenthetical) comment, >I have to make an exception in this case. I dont think that you want the >emacs interface to produce the illusion of a single program at all. >In the name of this illusion, the Quintus Prolog emacs interface has >the following "features": [specific criticisms deleted] There are two separate and distinct questions: (1) whether an editor interface should present the illusion of a single program (2) what changes to an editor are permissible/desirable in the name of simplifying a particular interface. The points that Dowding criticised are all related to question (2), not to question (1). The changed key bindings are not at all "in the name of this illusion", they are all things that the designers of that part of the system thought were desirable whatever the interface looked like. With respect to question (1), does anyone think it would be a _good_ thing for Prolog and Emacs to have a different notion of what the current directory is? Or of what the current state of a file is? By the way, if you are using Quintus Prolog and have comments about our editor interface (or anything else), **please** send them to our Technical Support people. The editor interface is not cast in concrete, but if nobody complains to us we think it doesn't need changing. -------------------------------- End of PROLOG DigestMODERN P5/z1z: