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.
Paper already mentions -- Haskell with logic extensions:
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.
A well-maintained / open-source implementation: http://potassco.sourceforge.net
An introductory paper: http://www.aaai.org/Papers/AAAI/2008/AAAI08-270.pdf
...and to his home page:
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.
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?
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.
Even got 3rd place on the Portuguese Logic Programming Contest.
I guess Erlang might be the way of keeping it somehow alive in the industry.
Ah, yes. My first reaction to seeing pattern matching in ML: "Hey, this is literally half of unification."