The birth of Prolog (1992) [pdf]
alain.colmerauer.free.fr
alain.colmerauer.free.fr
Prolog and Logic Programming Historical Sources Archive - https://news.ycombinator.com/item?id=22658770 - March 2020 (33 comments)
The Birth of Prolog (1992) [pdf] - https://news.ycombinator.com/item?id=18178215 - Oct 2018 (39 comments)
A Tribute to Alain Colmerauer (2001) - https://news.ycombinator.com/item?id=15254369 - Sept 2017 (1 comment)
In Memoriam Alain Colmerauer: 1941-2017 - https://news.ycombinator.com/item?id=14399688 - May 2017 (5 comments)
Others? Prolog itself is probably too big a theme to list here, but Prolog origins?
(Edit: thanks to commenter who supplied now-deleted reference.)
https://www.cse.chalmers.se/edu/year/2009/course/TDA381_Conc...
It's quite amazing how one can implement Erlang or basically any other language prototype as a Prolog metainterpreter.
For more information see the following:
"Information Security Requires Strongly-Typed Actors and Theories"
The rationale? It would be a child's play if we used them.
See the following for further information:
"Middle History of Logic Programming: Resolution, Planner, Prolog and the Japanese Fifth Generation Project" ArXiv 2009.
I would really like to read more about Planner, but I have had no luck searching for this paper.
When I couldn't find the paper in arxiv, it didn't occur me at first to go back to the beginning and use a general search engine. When I did plug the title into DDG it took me to arxiv, which had the expected abstract and a working link to the pdf. But doing another search in arxiv returned "No Results", even though I had put in the exact title from the abstract I was just looking at.
A little more digging uncovered the fact that the paper in question has gone through 41 revisions, and somewhere along the line the title was changed from "Middle History of Logic Programming: Resolution, Planner, Edinburgh LCF, Prolog and the Japanese Fifth Generation Project" to "Inconsistency Robustness in Logic Programs", which is still rattling my brain a little bit.
edit: The working link I found is https://arxiv.org/abs/0904.3036v22
https://arxiv.org/pdf/0904.3036.pdf
seems like your link is versioned (v22) and the one i found was unversioned... i wonder which one is the latest...?
From the featured article: "It was at this time that we learned of the existence of Carl Hewitt’s programming language, Planner [20]. The lack of formalization of this language, our ignorance of Lisp and, above all, the fact that we were absolutely devoted to logic meant that this work had little influence on our later research."
Personally I think I'll believe Colmerauer on this one.
Being a linguist of note, Colmerauer evidently didn't know (or didn't
want to admit) that Kowalski had been carefully studying
Planner and Shrdlu (Winograd's Phd thesis based on Planner)
for quite a while in Edinburgh, where he felt quite in the
minority defending pure mathematical logic against the
onslaught of Popler (Pop2 Planner), etc.
The formalization issue was addressed by the invention of
Actors for all of digital computation including many
computations that cannot be performed using pure logic
programming (including Colmerauer's Prolog).
Furthermore, many practical applications can be implemented
using Actors hundreds of times faster than they can be
implemented using pure logic programming.
PS. Have you actually read the article"Middle History of Logic Programming: Resolution, Planner, Prolog and the Japanese Fifth Generation Project"
ArXiv 2009.
At MIT criticism of resolution which led to the development of the Planner language of Carl Hewitt and its use by Terry Winograd to implement a large portion of his PhD thesis which was extremely influential at the time... and this was promoted as an alternative to logic and as a procedural representation of knowledge as opposed to a declarative representation of knowledge. So this [muddied] the waters [so to speak] and it created enormous confusion. On the one hand you have resolution [...] logic and its applications to problem-solving, then you have the Planner language which is characterised as a procedural approach alternative to logic and yet it was clear to me that there where [similar to others] the Planner language had similarities to resolution which which were not understood and it was trying to understand that relationship and that similarity that I would say gave rise to logic programmign as I characterised it so far.
The podcast can be found here (I'm not afiliated with it in any way):
The passage above starts at around 29:53. My apologies for the poor quality of the transliteration.
>> Planner and Shrdlu (Winograd's Phd thesis based on Planner)
Terry Winograd's SHRDLU remains pretty much unsurpassed as a system even today. Wikipedia quotes an excerpt from Winograd's thesis that lists a dialogue between SHRDLU and its user. There's a particular exchange that blows my mind every single time I read it:
Person: Does the shortest thing the tallest pyramid's support supports support anything green?
Computer: YES, THE GREEN PYRAMID.
https://en.wikipedia.org/wiki/SHRDLUI mean, at that point he's just showing off! I can only imagine him snickering to himself imagining the faces of people reading that.
Still, for me personally resolution has proved to be the right way to go, historically. In particular, I'm prepared to bet that Terry Winograd would have saved himself a lot of pain had he been able to use Prolog's Definite Clause Grammars to write SHRDLU's natural English parser. In Prolog, a grammar, even a natural language grammar, is a theorem and parsing it is a proof, just like for every other program; in every other language a grammar is the input to a program that must be written specially for the task of parsing.
My criticism at the time was about resolution uniform proof
procedures. I was skeptical that a single procedure could
prove typical complex mathematical theorems. Procedural embedding
of knowledge was invented to overcome the limitations of
resolution uniform proof procedures.
Unfortunately, resolution requires flattening the structure of
a mathematical propostion into clausal form thereby
losing all of its structure. An important innovation of
Planner was *not to require conversion into clausal form.*
Instead, each Planner backward-chaining procedure is invoked
by a noncompound goal. Furthermore, each Planner forward-chaining
procedure is invoked by a noncompound assertion. Prolog is a
subset of Planner in which a Prolog procedure is invoked by a
single noncompound goal. *Prolog does not have forward chaining.*
BTW, Kowalski and I continue to disagree about fundamentalnature of pure logic programming. My thesis is that a logic
program is characterized by the requirement that each
computational step must be completely justified by a rule of
mathematical logic.
About flattening the structure of a mathematical proposition, I think I understand what you mean, but that should not really be a problem. It should be possible to express a mathematical (or anything) concept in different formalisms without losing its meaning. The structure itself is not that important, as long as the meaning remains the same. Horn logic happens to be a formalism that is both maximally expressive and semi-decidable (SLD-resolution is sound and complete for refutation, or with subsumption). Given that it can also be communicated to a computer without any further changes of formalism, it is also very useful.
In any case, thank you again for your contributions to this thread and your replies to my comment. Your perspective of logic programming is invaluable.
By "a rule of mathematical" logic, I meant a standard logical
inference rule such as Modus Ponens or Double Negation Elimination.
No modern proof engine requires flattening a proposition into
clauses, which often makes the proposition more difficult to understand and process.
Just because the clauses are logically
equivalent doesn't that they are always useful.
Thank you very much for your own contribution :-)A resolution uniform proof procedure had the problem that once
all the propositions had been flattened in to clauses, the
proof procedure did not have a good idea where to focus its efforts.
edit: to be clear, in the book you interpret a logic programming language with lisp-like syntax
Also worth exploring The Reasoned Schemer which teaches minikanren, which can be (and has been) implemented in many programming languages. It explores much of the same space as Prolog. I wrote most of a minikanren in Common Lisp while working through the book (someone else had already published a version to quicklisp which was better than what I made).
I swear I'd bookmarked a resource that was more analogous to #2, but you may want to have a look at The Little Prover: https://mitpress.mit.edu/books/little-prover
Will Byrd has a lot of documentation out there. (Scheme focus of course.)
I think the easiest way for a programmer with a vanilla background to “get it” is here:
[1] https://en.wikipedia.org/wiki/Warren_Abstract_Machine
[2] https://www.cse.unt.edu/~tarau/research/2017/eng.pdf
[3] https://www.t3x.org/bits/prolog6.html https://news.ycombinator.com/item?id=20591771
I don't know anything about it but there's "Prolog.c: a simple Prolog interpreter written in 200 LOC of C++ (2000) (cam.ac.uk)"
https://www.amazon.com/Reasoned-Schemer-MIT-Press/dp/0262535...
There's also Implementations of Prolog: https://archive.org/details/implementationso0000unse (limited preview)
Pages 87-92 contain the article "The world's shortest Prolog interpreter?" by M. Nilsson of Uppsala University. The article describes and provides source code for a simple Lisp implementation of Prolog.
Edit: Oops. After posting my comment, just saw DonaldFisk's comment here: https://news.ycombinator.com/item?id=26244021 So Norvig's PAIP may be the book where I saw it.
Edit 2: Also just saw gglitch's comment:
https://news.ycombinator.com/item?id=26242603
which confirms my first surmise about both the PG and Norvig books containing it.
[0] - e.g. https://trs.jpl.nasa.gov/bitstream/handle/2014/7660/03-1728....
Most of that page is about character escaping as well as Unicode and floating point corner cases. You'll need to handle the same corner cases if you want to write a robust Prolog parser (it's slightly simpler if you cheat by rejecting Unicode).
:- op(600, xfy, :).
MyJSON =
{ "this": "bla",
"that": 100,
"L": [ 1, "two", 3 ] }
provided your Prolog has curly braces (should come with DCGs).