Robert Kowalski

Prolog stands for "programmation en logique", and as might be guessed from that comes from France (Alain Colmerauer in Marseille, to be precise). Now Kowalski, who also was an important pioneer in logic programming who collaborated with Colmerauer did work in Edinburgh, but from the horse's mouth: I have tried to document as best I could our various contributions to that idea in an article published in CACM, 1988, and more recently in a History of Logic Programming, published in 2014. In summary, however, it is probably fair to say that my own contributions were mainly philosophical and Alain’s were more practical. In particular, Alain’s work led in the same summer of 1972 to the design and implementation of the logic programming language Prolog. https://www.doc.ic.ac.uk/~rak/history.pdf

A classic reference: The British Nationality Act as a Logic Program: https://www.doc.ic.ac.uk/~rak/papers/British%20Nationality%20Act.pdf Parts of the constitution of Japan in Prolog: https://github.com/bitlaw-jp/the-constitution-of-japan A recent project involving the formalization and automated analysis of criteria for grants: https://www.brz.gv.at/en/BRZ-Tech-Blog/Tech-Blog-7-Symbolic-Analysis-o…

Meh. As usual, functional programmers look at Prolog and completely miss the point. "Classical Prolog" (which part?) is "all about nondeterminism"? The nondeterminism in Prolog comes from the completeness of SLD-Resolution as an inference rule. Because SLD-Resolution is complete [1], it can find every proof that exists. When there are many proofs, it is natural to have some mechanism to represent them all. Prolog does that by backtracking and trying different branches of a proof, hierarchically. Parsing is indeed a good example of this. When a grammar is ambiguous, a string may have multiple different parses. But if a grammar is ambiguous, that's because the language it represents is ambiguous, and that means we want to represent the ambiguity, and have multiple parses. That is where a mechanism for nondeterministic return of all results is needed. A parser written in Prolog [2] will naturally backtrack and get all parses of a string. So how about that maudlin cut, that people, like the authors of the article above, have bitched and moaned about, since the creation of Prolog? Well the cut clearly exists to avoid reaching unwanted branches of a proof, or in other words, to avoid unwanted backtracking. But why then is there unwanted backtracking? The reason for unwanted backtracking is, invariably, that a program is over-general. In over-generalising, the program non-deterministically generates results that the programmer did not want, even as it returns (hopefully first)…

I've been working on this (albeit as a library rather than a language in its own right). The more papers I read the more lost I became trying to make sense of the different approaches to goal-oriented / relational / logic programming. This retrospective paper by Robert Kowalski gave me an historical framework to make sense of it all: https://www.doc.ic.ac.uk/~rak/papers/History.pdf One of the key insights I gleaned from that paper is the difference between bottom-up and top-down strategies. All logic / relational / goal oriented paradigms exhibit a characteristic top-down or bottom-up quality, and this classification can then be used to understand the essence of goal-oriented programming. The following is my interpretation of the historical information from that paper: During the 1980s a burgeoning Datalog community, with roots in the database field, assimilated the existing deductive database community which had roots in AI. The database perspective focuses on finite models that are computable bottom-up. However a naive bottom-up implementation, deducing forwards from facts using rules, ignores the query until it derives it "as though by accident." To make generated models relevant to the query, Datalog uses transformations such as "Magic Sets" to incorporate the query into the rules. An early deductive database (AI) strategy was Hyper-resolution, which is essentially also bottom-up, and it suffers from the same problem of generating new derivations blindly…

Trying to track down some other reference, I see that there was work on formalising British nationality -- in Prolog! -- in 1986: https://www.doc.ic.ac.uk/~rak/papers/British%20Nationality%20Act.pdf

Some of these articles were written by Robert Kowalski (homepage: http://www.doc.ic.ac.uk/~rak/), who was part of the initial Prolog gang/community, which was split between Marseille (FR) and Edinburgh (GB). This year, PROLOG turned 50 years!

Logic oriented programming is really well suit for this problem. Most complaw research happen in the logic department of universities. - blawx.com use ergo 2 in the backend - Kowalski ( author of iso prolog ) wrote a paper on the topic in the 80's http://www.doc.ic.ac.uk/~rak/papers/British%20N ationality%20Act.pdf

Prof. Kowalski has a draft version of his book available on his website, which should provide background information on LPS: http://www.doc.ic.ac.uk/~rak/papers/newbook.pdf Computational Logic and Human Thinking: How to be Artificially Intelligent "This earlier draft of a book of the same title, published in July 2011 by Cambridge University Press, presents the principles of Computational Logic, so that they can be applied in everyday life. I have written the main part of the book informally, both to reach a wider audience and to argue more convincingly that Computational Logic is useful for human thinking."

Robert Kowalski (1979). "Algorithm = Logic + Control". Communications of the ACM 22(7): 424-436. http://www.doc.ic.ac.uk/~rak/papers/algorithm%20=%20logic%20+%20contro… (It's the paper that originated Prolog, but is also more broadly interesting for its analysis of, well, algorithms as logic plus control.)

Very interesting. The demo on pp 376 looks useful. From the conclusion: > The British Nationality Act 1981 has also proved to be a rich source of problems for the use of logic for knowledge representation. It has highlighted problems with negation as failure and counterfactual conditions in particular. We believe that the formalization of legislation and the development of computer systems to assist with legal problem solving and decision making provide a rich domain for developing and testing artificial intelligence technology. More tentatively, the accumulated experience of managing complex systems of law may teach us something about the maintenance of large bodies of complex software. Here's another paper by one of the authors, "Legislation as Logic Programs" from 1991: http://www.doc.ic.ac.uk/~rak/papers/law.html > In addition to the resemblance between legislation and programs, the law has other important similarities with computing. It needs for example to validate legislation against social and political specifications, and it needs to organise, develop, maintain and reuse large and complex bodies of legal codes and procedures. Such parallels between computing and law suggest that it might be possible to transfer useful results and techniques in both directions between these different fields. One possibility explored in this paper is that the linguistic structures of an appropriately extended logic programming language might indicate ways in which the language…