🚀 go-pugleaf

          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?