Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!pasteur!agate!violet.berkeley.edu!lagache From: lagache@violet.berkeley.edu (Edouard Lagache) Newsgroups: comp.lang.prolog Subject: Re: PROLOG as a "real" language (how about just a complete one?) Message-ID: <8358@agate.BERKELEY.EDU> Date: 5 Apr 88 04:20:52 GMT Sender: usenet@agate.BERKELEY.EDU Reply-To: lagache@violet.berkeley.edu (Edouard Lagache) Organization: University of California, Berkeley Lines: 86 Keywords: Completenesss, language features, Programming flexibility I knew I was going to take some heat for my "vain" defense pragmatic PROLOG programming. But at the risk of wasting more breathe, I would like to defend myself against the comments of Paul Voda. In article <1926@ubc-cs.UUCP>, voda@ubc-cs.UUCP (Paul Voda) writes: > >This is a response to the claim by E. Lagache that he prefers a practical >and dirty Prolog before a logically pure and "impractical" one. > I strongly disagree with this characterization. What I want is a finished, working PROLOG programming language, instead of a incomplete, half-patched, unpolished research plaything. I have no objections to people trying to develop a more effective and elegant form of logic programming, I *strongly* object to people tinkering with a language with a large user base and thousands of applications. You want to make a better logical programming language - wonderful, just don't call it PROLOG unless it can run the thousands of lines of PROLOG code that is already out there. >The Prolog community is split into two groups. > > [ What follows was a discussion of various views on PROLOG efficiency ] Will somebody please explain to me that this has to do with my note? As some of you may recall, My main beef was increasing the number of predicates that can generate error conditions. The basic for this complaint is the lack of error trapping in (standard) PROLOG which makes in impossible way to recover from unexpected program errors which is *very* important in a practical user application (ever heard of "graceful error recovery"?). Which get me back to my original point. If PROLOG is going to become a practical language, it is going to need practical tools that are needed in real world programs. Things like: error trapping, good file access, flexible and powerful predicate libraries to work on everything from numerical analysis to tinkering with system internals (both the PROLOG and operating systems), AND USER INTERFACE TOOLS! I don't know what bearing such additional capabilities would have on the "logic holiness" of PROLOG, but I don't see any obvious reason why these capabilities couldn't be added in a manner in keeping with the spirit of PROLOG. Perhaps instead of moaning about how PROLOG has lost all its structure, the logic purists out there should consider how one might go about adding all those capabilities in a "declarative" manner (anyone got a good declarative representation for window operations?) >But Lagache wants both have the cake and eat it. >He unabashedly proclaims himself to belong into the first group, yet >not so long ago he offered to the logic community his own library >of Prolog predicates. How does he think anybody will accept the >library if there is no way to logically describe the "predicates" >contained in it? Before a predicate is accepted it must have >a clear specification (declarative reading). Knowing that the author >does not care about these things (and some of the "predicates" in the >library are really badly designed) I would never contemplate using it. I find this comment most amusing. Many of my predicates were either taken directly from Clocksin and Mellish's book or were coded in a similar style - Does this mean that Paul Voda is prepared to make the same comment about Clocksin and Mellish? I would greatly appreciate if people would stick to the facts in the future. Personal attacks have no place on the net. Edouard Lagache PROLOG Forum lagache@violet.berkeley.edu P.S. My comment about PROLOG not being complete shouldn't be interpreted as meaning that all existing PROLOGs are incomplete. On the contrary, there are a number of outstanding implementations, but that is precisely the problem. If you stay within the proposed standard your language really won't be complete. If you extend your system, in what sense are you "really" standard?