The best thing about prolog is how naturally search happens: state facts and rules once, then query them in many different ways. The worst part is, as the paper describes, constantly having to curb this search so that Prolog runs efficiently for normal deterministic code.
Another missing piece that this paper picks up: in the real world we want to generate options in order of likelihood. The Alchemy project for AI incorporates probability this way. My understanding is that it doesn't unfortunately doesn't scale well.
Shameless plug: I revisited Prolog in recent times and wrote Marelle, a tool for test-driven sysadmin. The language is clunky by today's standards, but I still haven't seen nicer syntax for writing non-determinism.
My feeling is that prolog as a language hasn't aged as well as it could have, so learning it now is mainly as a mental exercise. Something like Mercury shows more of the potential of logic programming, seating it properly alongside functional programming as it should be.
In my experience Prolog is best as a user interface. The ability to explore through querying the clauses database and compose and explore different modes without writing throw away code is a real pleasure. Imagine a Prolog style command shell: the datalog semantics compose really well (basis of database queries), the naive search obviates writing throw away functions just for command line use, two way data flow through logical variable and unification significantly reduce the mental load needed to remember variations of function names etc.
It is a pity this is not done more often in practice. It is rather easy to write FFI functions for Prolog if efficiency is a concern. Embedding Prolog style computation inside another language, as the paper has done, seems to me to miss the point. It is the Prolog programming environment that I appreciate the most.
The problem with Prolog is the need to rewire your brain to think in Prolog. I remember struggling for many hours to solve a problem and hitting a wall. But then when it is solved in Prolog it would be something like 10 lines of code.
It kind of reminds of understanding and writing math formulas. It would take days to decipher a one-line formula.
There's a fairly large part of the ex-Prolog community that decided to go all-in on the declarative part, partly in reaction to that, and partly in reaction to other warts in Prolog's semantics, like the fact that statement order is significant. There was a period when logic-programming theorists were trying to come up with what Prolog's semantics would be, if you assumed it was possible to give it a vaguely logic-style semantics versus defining its semantics as "whatever SLDNF gives you". One of the proposals that came out that was the "stable model semantics". And that gave rise to a purely declarative logic-programming paradigm, answer-set programming. That has then turned out to mesh well with modern developments in SAT/SMT/etc. solver-style systems, instead of Prolog's more classic backtracking search, so sits at some kind of intermediate space where it's about equally influenced by the logic-programming heritage and the "solver" heritage.
This. I'm no Prolog expert, but every time I come back to it I remember how elegant canonical problems are to solve with it. I absolutely love the declarative style. More languages need to have logic extensions a la core.logic for Clojure, various Kanrens for Scheme. I would love to see computer scientists make advancements in logic programming.
It's just the way you phrased it, core.logic for Clojure, various Kanrens for Scheme, as opposed to, implementations for Kanren in Clojure and Scheme such as core.logic.
Came highly recommended by David Nolen on his blog. Appears to have a good section on CLP.
EDIT: And completely agree with you on "The Art of Prolog", I have that too and have read most of it. Need to get back to finishing that up some day ;)
Every time I mess with Prolog [which is once a year, as I cover it in my Programming Languages class] I have the same two thoughts:
(1) This is nifty stuff, but I wouldn't want to program this way all the time. Rather, Prolog-ish computing should be available as a library in some more conventional language.
It's nice to see that the authors of this article are thinking at least somewhat the same way.
(2) This isn't really logic programming. A Prolog predicate with no inputs and one output is a stream. A predicate with one input and one output is a parametrized stream. A predicate with one input and no outputs is a filter for a stream.
Streams are everywhere in modern PL design: Python iterables and Haskell lists for example. C++ seems to be moving slowly in the direction of some kind of coherent stream spec. (think about range-based for loops). And Prolog has some really nice stream-handling ideas that other languages would do well to adopt.
But Prolog people don't think that way. Instead of seeing Prolog as a stream-based language, they see it as a sort of rough draft of a logic-based language, and they wonder how to move it more in the direction of pure logic. Could this be a misguided idea?
(Infinite) streams can be seen as really fundamental codata constructions as well. They're `nu (a )`, so if you believe that both codata and products are necessary then you have streams.
A lot* of people have rejected the first of those for most of the history of mathematics, but nobody rejects the second. Thus, streams are exactly as popular as codata/anti-foundation is.
As for binding, yes, you can come up with similarly looking examples, but they are different in essence: Erlang has pattern matching, while Prolog has unification.
I'm kind of wondering why we haven't seen any notable (unless I've missed something) languages with full unification escape from academia into wider use since Prolog -- I know on the academic side there is Oz, which is a very interesting language, but I don't get the impression that its seen much, if any, use in industry.
Another missing piece that this paper picks up: in the real world we want to generate options in order of likelihood. The Alchemy project for AI incorporates probability this way. My understanding is that it doesn't unfortunately doesn't scale well.
http://alchemy.cs.washington.edu/
Shameless plug: I revisited Prolog in recent times and wrote Marelle, a tool for test-driven sysadmin. The language is clunky by today's standards, but I still haven't seen nicer syntax for writing non-determinism.
https://github.com/larsyencken/marelle