voda@ubc-cs (Paul Voda) (04/04/88)
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. If this outrageous claim were made by somebody else I would not bother to polemize. Either the person is making a bad joke or else he should not be a logic programmer. In the latter case he should use C possibly amended by some backtracking primitives. But since the claim was made by Lagache I think that a rebutal is required. The Prolog community is split into two groups. The first group is willing to sacrifice the logic in order to attain efficiency. These are the assert, retract, and var users who want to have all the goodies from the procedural languages (arrays, reassignable variables, exceptions) right now. The only thing that matters to them is the efficiency. The people in the second second group think that if the logic programmers will not care about logic nobody will. Quick hacks are repulsive to them. There are two subgroups in this group. The first subgroup thinks that the language should not be extended but rather the compilers must become smart enough to recognize an optimization (for instance the automatic detection of reusable memory). The people in this group are willing to live with the inefficiency in the hope that the research will eventually solve the problem. The second subgroup (I count myself here) is willing to extend the language provided the extensions can be logically explained. The logic is primary but if the efficiency can be obtained via an extension I do not mind the extension. 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.
lagache@violet.berkeley.edu (Edouard Lagache) (04/05/88)
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?ok@quintus.UUCP (Richard A. O'Keefe) (04/05/88)
In article <1926@ubc-cs.UUCP>, voda@ubc-cs (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 think that it is a serious mistake for the BSI committee or anyone else to try to "purify" Prolog, and although I tend to sit on the same sort of fence as Lagache I think that this point of view can be defended from both sides of the fence. On the "let's have a practical language" side, the plain fact is that you can learn to work around the limitations of any tool if only it will stay put. Prolog-as-we-know-it has defects, but it is an excellent tool none the less. I have no idea how to use BSI Prolog effectively. On the "let's be serious about logic" side, surely it is clear that _neither_ trying to write super-smart compilers _nor_ extending Prolog is the right idea. Voda himself has done neither of these things, but has produced a new language. If you don't have to support existing programs, you have a _lot_ more freedom to design your language to make optimisation more straightforward. There are people working on partial execution, data flow analysis, better compilers, and all sorts of exciting things, and that's great, and should influence the design of Prolog's successor. What is to be avoided is the people who want a cleaner language forcing the present inefficiency of partly baked ideas onto people who just want to get the job done. The thing which triggered the present topic was, I believe, my mention of the BSI group's changing the definition of atom/1 rather than adding a new is_atom/1. Note that this taste for purity hasn't led them - to eliminate var/1 - to replace cuts - to replace assert/1 and retract/1 (it's now determinate, but there) - to introduce sound negation - to introduce a sound all-solutions predicate or anything else of that sort. That is no serious attempt to produce a language closer to logic.
steve@hubcap.UUCP ("Steve" Stevenson) (04/06/88)
From article <1926@ubc-cs.UUCP>, by voda@ubc-cs (Paul Voda): > The first group is willing to sacrifice the logic in order to attain > efficiency. These are the assert, retract, and var users who want > to have all the goodies from the procedural languages (arrays, > reassignable variables, exceptions) right now. The only thing that > matters to them is the efficiency. Even though you claim to eschew polemics, seems you fell into it anyway. IF prolog is to be a good model then it must offer to deal with all current issues - that's what equivalence of language means. If you insist that arrays are not legitimate, then how will you address mathematics? I have had several numerical types who say they really like the idea of prolog, but no arrays makes it impossible to consider "numerical logic programming." Let's pull together, folks. -- Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
ok@quintus.UUCP (Richard A. O'Keefe) (04/07/88)
In article <1315@hubcap.UUCP>, steve@hubcap.UUCP ("Steve" Stevenson) writes: > If you insist that arrays are not legitimate, then how will you > address mathematics? I have had several numerical types who say > they really like the idea of prolog, but no arrays makes it impossible > to consider "numerical logic programming." Let's pull together, folks. (1) Mathematics and numerical programming are not co-extensive. (2) If by "arrays" one means the rectangular structures found in Fortran and Pascal, bear in mind that large-scale numerical programming is to a large extent a matter of fighting around the limitations of such arrays (band matrices, triangular matrices, sparse matrix packages, generalised upper bounding, ...) (3) "Arrays" covers two things: constant-time *access* to large collections of data, and constant-time *update* of such collections. There's no reason why something like Trilogy couldn't be extended with the computational parts of APL. (4) The same absence of constant-time update is to be found in functional languages such as ML. Does this mean that it is 'impossible to consider "numerical functional programming"'? (5) It turns out that assignment to individual array elements is one of the principal reasons for there being so little potential parallelism in Fortran programs. There was a study which claimed to show that if you were prepared to build new arrays instead of copying old ones you could get 700-fold parallelism rather than 7-fold. (This is not an argument _for_ logic programming, just an argument _against_ blind faith in current practice.) Something I would like to do, if only I could find the time, is to write a linear programming routine in Prolog. I've done it before in a conventional language. The key to efficiency was the use of a particular sparse matrix representation. I believe that a couple of lists of lists of pairs will be an adequate Prolog encoding of the data structure. Would it not be more profitable for the "numerical types" to provide specific examples which they think cannot be done efficiently in Prolog or ML, rather than to refuse to consider it?
steve@hubcap.UUCP ("Steve" Stevenson) (04/11/88)
From article <855@cresswell.quintus.UUCP>, by ok@quintus.UUCP (Richard A. O'Keefe): > In article <1315@hubcap.UUCP>, steve@hubcap.UUCP ("Steve" Stevenson) writes: > (1) Mathematics and numerical programming are not co-extensive. Agreed - I forgot "numerical" > (2) If by "arrays" one means the rectangular structures found in Fortran > ... large-scale numerical programming is a matter of fighting > around the limitations of such arrays ... Agreed - Fortran is not coextensive with numerical :-). The obvious thing is to realize that fact. The idea is to straighten the problem out not ignore it. > (4) The same absence of constant-time update is to be found in functional > languages such as ML. Does this mean that it is 'impossible to > consider "numerical functional programming"'? Last time I checked, that was the case. I have been away from functional models for a while. > (5) It turns out that assignment to individual array elements is one of > the principal reasons for there being so little potential parallelism > in Fortran programs. There was a study which claimed to show that if Sorry, but you seem to have this fixation about Fortran and numerical processes be the same. It certainly is not. I don't recall seeing anything in Isaacson and Keller to that effect. But certainly the problems of updating and misshaping of arrays comes about from such a limited model. BTW, APL is not much help and LINPACK is even worse. My question remains. Why not include "matrix" processing. Let's call them matrices to differentiate from the data structure. There very elegant proofs in real and complex analysis which use matrices and certainly seem to work just fine. Perhaps you mean the "unrestricted use of assignment in array structures." It's easy enough to think about a linear solver in prolog, but I want you to do Gauss-Seidel with a normal PDE in mind. Normal being LARGE and SPARSE. -- Steve (really "D. E.") Stevenson steve@hubcap.clemson.edu Department of Computer Science, (803)656-5880.mabell Clemson University, Clemson, SC 29634-1906
ok@quintus.UUCP (Richard A. O'Keefe) (04/12/88)
In article <1352@hubcap.UUCP>, steve@hubcap.UUCP ("Steve" Stevenson) writes: > From article <855@cresswell.quintus.UUCP>, by ok@quintus.UUCP (Richard A. O'Keefe): > > (5) It turns out that assignment to individual array elements is one of > > the principal reasons for there being so little potential parallelism > > in Fortran programs. There was a study which claimed to show that if > > Sorry, but you seem to have this fixation about Fortran and numerical > processes be the same. You cannot derive that from what I said. This particular point was about updatable arrays, not numerical processing, and I specifically said Fortran because the particular study I have in mind studied only Fortran programs. > My question remains. Why not include "matrix" processing. Let's > call them matrices to differentiate from the data structure. There > very elegant proofs in real and complex analysis which use matrices > and certainly seem to work just fine. Perhaps you mean the "unrestricted > use of assignment in array structures." If by this you mean some sort of collection which must be accessed fast but does not require the ability to change individual elements, why not indeed? There is a paper D. Wise Matrix Algebra and Applicative Programming Conference on Functional Programming Languages and Computer Srchitecture September 1987. I haven't got a copy of this paper, and I would be grateful if anyone who has seen it would give me a more precise reference so that I can get a copy. But the citation said "This approach [of emulating arrays using lists or trees] may not be entirely invalid: [Wise 1987] provides an argument that for certain numerical problems, trees are adequate." > It's easy enough to think about a linear solver in prolog, but I > want you to do Gauss-Seidel with a normal PDE in mind. Normal being > LARGE and SPARSE. Actually, what I said I want to do is linear programming (simplex method), not a "linear solver", and "large" & "sparse" are exactly the characteristics of such problems which make me think the existing resources of Prolog and ML may be sufficient. They are certainly the characteristics which make arrays as found in ADA or Modula-2 rather more clumsy for the application than one would care for. Certainly these large sparse structures I think we'll all be able to discuss the topic more intelligently when we've had a chance to read the paper cited above, and I repeat my request for a more precise reference so that I can do so.