Pereira%SRI-AI@sri-unix.UUCP (10/17/83)
I didn't explain myself well, I see now. The "impure" parts of Common Lisp are the result of the codification of 20 years of Lisp practice by 1000s of practicioners. Most of these impurities are there for good reason, to circumvent limitations of the language or of our ability to design smart compilers (E.g. compilers that transform inefficient copying into efficient replacement). However, the situation with Prolog is very different: only recently has Prolog started being used by a sizeable community, and many of the impurities in Prolog are "quick and dirty" solutions to problems the original impementers could not afford to think through. Given that there has been much less exploration of the Prolog "problem space" than is the case for Lisp, it is more likely that principled solutions can be found for problems that currently are solved in a "ad hoc" way in Prolog. That's why I think that attempting to enshrine today's poor Prolog practices will in the long term be detrimental to the good health of Prolog and logic programming. I was not suggesting that people should stop using "impure" features when they need them to get the job done (that would be the authoritarian, "diamond" approach). I just intended to say that expediency should not be promoted to principle. With respect to the specific issues under discussion, I don't know of anybody who has thought through the question of failure vs. error in builtin procedures, or the question of what kinds of database modification are suitable for different tasks in Prolog. I would certainly be disappointed if the current mess in the Prolog systems I know (and which I helped to create...) were to be perpetuated or exchanged for "ad hoc" solutions slavishly copied from other languages without concern for the differences between those languages and Prolog. The approach I wish Prolog implementers would take is to some extent that of the Common Lisp effort, but helped by the better theoretical understanding which I am sure it is possible to achieve given the nature of Prolog and the lack of effort in this area. -- Fernando Pereira