Might be useful for the folks who want to learn how the language ticks but don't have the time to go through a whole book.
That being said, the book is pretty great! I recommend it.
^^ I found to be very helpful in learning enough of Prolog to make a bracket for the 2018 World Cup
The art of efficient in prolog is understanding your database, facts, and your search space and how to trim it. If you need 3 items, search for 3 items only, don't search for all possible items then try to pick 3.
If you can figure out when to cut your search, do so.
For deterministic operations that you can meomize, do so.
If your system supports tabling use it.
Difference list is like the TCO of Prolog, the efficiency can be amazing.
The difference in performance between an average programmer and a pro prolog programmer is usually much more than you will find in other languages.
Prolog should also be very popular with developers who like pattern matching and destructuring; it's pattern-matching by unification is, er, unmatched.
Prolog is also excellent for DSLs, either usings it's built-in facility for defining new functors (unary or binary operators/keywords), or standard DCG recursive-descent parsers or more complex grammars. Prolog was designed for NLP, used for prototyping Erlang, and a major inspiration for Haskell after all.
But yeah, it involves quite a lot of backtracking, that happens when the resolution engine needs to go back and try something different. When this is a problem you can sometimes use the cut rule http://www.cse.unsw.edu.au/~billw/dictionaries/prolog/cut.ht...
What a con, I'll be sure to avoid anything like that in future.
"Prolog is just a brute force search" -> "Prolog is a brute force search"
and then reference the Gary Larson comic ( https://pics.me.me/the-far-side-by-gary-larson-3-23-hey-wait... ) where the cow suddenly realises what they've been eating is /grass/.
All libraries are "just" some code which does something so you don't have to. Even if Prolog is "just a brute force search", well in the same kind of way, regex is "just" a state machine brute-force matching against a string. It's still a useful tool.
CHR (constraint handling rules) is a forward chaining system built into most prologs that has prolog like syntax, and so is a replacement for business rules engines.
So the choice of what to use is based on that (if you want forward chaining - business rules, or CHR of prolog), if you want backward chaining (similar to SQL) then prolog.
Prolog is more elegant than the business rules engines, and also has extra features (constraint programming with finite domains for example), that business rules don't have.
So in short, prolog is more comprehensive and more elegant but requires more expertise, busines rules are for "untrained" people to get working with relatively quickly.
Allows for rules such as
problem_in_kitchen and no_water_from_outside
TLDR: learn Prolog
'Paradigms of Artificial Intelligence Programming' by Peter Norvig. The book teaches both LISP and classic AI.
The drawback of metainterpretation is that it is, well, an interpreter layered on top of (on many systems) another interpreter. If you need your Prolog code to be really really "fast", then this approach may be "too slow". (Quotes because people love complaining about the speed of computation even in many situations where it really does not matter.)
A different approach is to use code generation. Prolog programs are collections of Prolog terms; once you have written the abstract computation you want, you can write a program that takes that code, mangles it into a different form, then compiles that new form just as if you had written it by hand.
So in summary, the separation you ask for is not there, but you have much more powerful tools than most other languages to implement it yourself quite easily.
It's like driving a truck and then learning to try a sports car cautiously like an overloaded truck, you won't enjoy it!
Lispers love to talk about "code is data" In prolog, "data is code" and until you grok that, it's really difficult to experience the Prolog enlightenment.
Just because structures, rules and trees are infinitely recursive doesn't mean no insight can be created from them in finite time.
Merely pointing out that someone else isn't correct might even have negative net value. For one thing, it can be construed as simple disagreement, opening up a debate that shouldn't happen when there really is a definitive answer. For another, it's insulting (especially as you did it) and that's not a necessary part of correcting someone's understanding.
Invest a few more minutes next time to actually make a substantive comment. You'll be helping the person you correct, you'll be helping whoever else reads the thread, and you'll ultimately be helping yourself – by opening up your views to an actual constructive process.
Also sometimes reordering clauses in the body of a rule is enough to avoid infinite runtime.
Datalog (or SQL + recursive CTE) don't have this problem.
Mozart/Oz or Alice allow to specify the search strategy.
You can encode your facts in prolog style syntax and save it in a file and that's your database. You load it, and then ask your questions at the REPL.
If you wanted data that multiple people can change, you can actually connect prolog to an SQL database, then using query apply prolog rules and ask questions about your data.
You're probably looking for Datalog. The Wikipedia topic has a list of systems that support it:
Also, I found that AllegroGraph is a production graph database that supports Prolog queries... I don't think you load it with Prolog syntax, though--probably RDF triples instead.
I have a copy of the book, and the code samples are really similar to Erlang.
A good description of what it's about is at MIT Press' page for the author .
(While out-of-print, apparently a paperback version can be had for $21 on Amazon ).
https://github.com/rm-hull/wam (WAM in Clojure)
https://github.com/rupertlssmith/hak_wambook (WAM in Java)
Can someone say which (who?) are the "Prolog for the 21st century" and the "Lisp of the 21st century" ?!
Also, using the SICStus interface and semantics for attributed variables should make for some very general constraint solvers, yes.
Tutorial available here (the "Ralph Becket Murcury tutorial" pdf) http://mercurylang.org/documentation/documentation.html
And just to tie this back to the original topic, Leon Sterling (first author of The Art of Prolog) was the head of the Department of Computer Science at the University of Melbourne when the development of Mercury began there.
"when the proof search accidentally returns the trivial case"
and both in open access~