Prolog for Beginners
coursera.org
coursera.org
That being said, learning about the inner workings of Prolog and how the WAM (Warren abstract machine) is composed helped me a lot to adjust my programming skills and align them to how things are best coded in the language.
But to be honest, myself I prefer to switch between the two paradigms at will when thinking about my programs. The trick is to do it in a way that leaves you with the best of both worlds, rather than the worst.
In terms of sources that go into more advanced material and avoid excessive procedural thinking, one is Markus Triska's website recommended in the sibling comment and I would also recommend Richard O' Keefe's "The Craft of Prolog" and Sterling and Shapiro's "The Art of Prolog".
To be fair, you won't find a lot of Prolog material in blogs so you can expect a lot to be left unsaid in the few that exist.
It is already a bit old, but you might have a look at it.
After that close understanding of logical operations like cut, or negation, and the most important was how certain operations could really impact performance to the point the were mostly "outlawed".
It's been years since I've used prolog, but I could probably pick it back up in a few weeks.
It turns out that transformations and rules engines are pretty generally useful, so Prolog makes a decent general-purpose programming language. It does take some getting used to, because its mode of operation is different from imperative and functional languages. You don't say, "do this, do that," and you don't present a functional expression for reduction to normal form. Instead, you write a set of facts and rules, then supply some initial conditions and let Prolog compute all the results that your rules imply. It can be a little brain-bending at first because most people seem to have an easier time with "do this, do that" than "this imples that, that implies the other thing."
On the other hand, for problems that are naturally represented as transformations or rules engines, it can be sort of magical. One fun detail is that, since you can specify the logical relations between terms and not an order of operations, you can commonly write Prolog programs that can be run "forward" and "backward" -- that is, given a transformation between A and B, if you supply A it computes B, and if you supply B it computes A.
That's interesting, but my hunch is that you'd need two deep learning models to do what a single Prolog program could do: one model to map inputs to outputs and one to map outputs to inputs.
One way to describe deep neural nets is to say that they are function approximators. Now, functions have well-defined inputs and outputs, although I don't think that's actual mathematical terminology. Functions are basically mappings from the elements of one or more sets _to_ the elements of another (or more) sets. But a function mapping is uni-directional. If you have a function ƒ: X → Y, it maps elements of X to Y, but it doesn't map elements of Y to X.
So for instance, if you have a function that maps the set of integers from 1 to 24 to the set of letters in the English alphabet, you don't simultaneously have a function that maps letters to integers- you need another function. This is true both in mathematical terms and in programming terms.
Suppose for instance that you have a Pseudocode function with signature:
int_char(int: n) -> char: c
int_char(2)
int_char("b")
In Prolog on the other hand there are no functions. Rather, every expression is a predicate, or in other words an n-ary relation. Now, the concept of relation is a generalisation of the concept of function, so in Prolog you could write int_char() above with the signature:
int_char(N,C).
?- int_char(2,C).
C = b.
?- int_char(N,b).
N = 2.
?- int_char(2,b).
true.
?- int_char(N,C).
N = 1, C = a ;
N = 2, C = b ;
N = 3, C = c ;
% ... etc
Anyway, deep learning learns functions, not relations, so its models can't go back-and-forth between sets in mappings. In theory anyway; deep neural net often don't really care about theory.
Let's say you have a collection of cities, and a collection of roads between them. And you want to answer the question: "is there a route from City A to City E?"
A solution in prolog would look something like this:
/* First, the roads */
road("A", "B").
road("B", "C").
road("C", "D").
road ("D","E").
/* Now the algoritm */
route(From, To) :-
road(From, To).
route(From, To) :-
road(From,Intermediate), route(Intermediate,To).
?- route("A", "E").
yes.Can't you just use the roads you've got as the base case and then say
road(X, Z) :- road(X,Y), road(Y,Z)
Because it creates a left-recursive call that will eventually cause a stack overflow. If you want to try it out, there's Swish[0] - an online prolog editor and interpreter.
Doing "high-level" model-building in a Prolog-like DSL might be interesting, but lower-level numerical code seems like a chore.
The real "value" of Prolog (in my novice estimation) is querying data (i.e. Datalog), transforming between data formats, and building "logic-driven" applications like command-line tools, API clients, etc.
How experienced? Inductive Logic Programming has been a thing since 1991 :-)
Not wanting to take away from your fascination ;) but even though Prolog is from 1972 (which may or may not be old, depending on your PoV), core Prolog syntax is pretty much a minimal language for representing terms and term unification. Doesn't get anymore straightforward than that, whether modern or not.
Prolog is by itself no language for number crunching or SIMD, nor does it usually deal with memory alignment, sparse matrices, or other data layout concerns in the way C++ for CUDA does. OTOH, Inductive Learning (ILP) has been a major application of Prolog as recent as 2012 (ProGolem, Aleph, etc., some of which have been taken into commercial endeavors). But I'm not familiar enough with ML to contrast with last decades's ML push/approaches, let alone have an opinion.
Not really, but the interesting thing about Prolog is ILP (inductive logic programming). ILP does things current deep learning can not: learning compact models, in a data-efficient manner, while utilizing explicit background knowledge. It has its own limitations though, related to noise tolerance, scalability and efficiency.
https://arxiv.org/abs/2101.05050
The experiments section shows one example of learning a program with a few thousand clauses and one example of learning with classification noise (i.e. misclassified examples), all in polynomial time and without "magic parameters" to overcome noise.
P.S. Er, actually I'm the corresponding author of that paper so eh, take my comment with a grain of salt as usual when researchers promote their research...
There would be a lot of noise, but there are big databases where the conclusions of clinical papers are already in predicate form.
What, really? Well in that case, that's ideal.
To clarify: yes, it's very very possible with the current state of the art. If you had unstructured text you'd have to do a lot of leg work to put it into a structured form, but if it's already in some kind of formal er form, then that's perfect.
I am interested, but I'm on the final year of my PhD and about to start on my thesis (I have a second paper to submit in May 1st, then it's thesis writing time after that). Which means I don't know exactly how much I can justify other work. But I would be definitely interested to demonstrate a real-world application of the system described in the paper I link to above. Or, if you're more interested in a different system, I can at least advise you how to use it.
Would you like to get in touch using the email in my profile? I trust you'll know how to use vim :-)
Some people at google seem to be working on this idea: https://opensource.googleblog.com/2021/04/logica-organizing-...
For some modern examples of learning Prolog programs with Prolog see:
1. Metagol:
https://github.com/metagol/metagol
2. Louise:
https://github.com/stassa/louise
3. Popper:
https://arxiv.org/abs/2005.02259
The first repo has a list of biblio right at the end, though it's a bit too formal maybe.
Full disclosure: I started my PhD on Metagol and Louise is my work.
For scientific computing, check out this paper:
Using logic programming for theory representation and scientific inference
https://www.sciencedirect.com/science/article/pii/S0732118X2...
And see repo with code here:
It could just be my bias, but everyone I have met who did some Prolog after Java and C said they found Prolog difficult.
None of my fellow Prolog-first cohort seemed to have any problems with other languages.
For example, how do you write fast Prolog? Often its fast but if its not, I feel a bit helpless. Are there any good articles with a bigger's look at Prolog performce?
Secondly, a teething problem which caused the video lectures to bring up an error screen has been fixed.
It's my first attempt at teaching (I hope that's not too obvious). I volunteered to be a guinea pig for Coursera's new "community guided project" courses, which has been very educational for me. I hope others manage to learn something from it too.
https://apice.unibo.it/xwiki/bin/view/Tuprolog/ for Java
http://tau-prolog.org/ for Javascript
Overall, I agree that there's a dearth of intermediate content out there.
Let's say a novice is someone who has no skill in a topic. A beginner is someone who knows a bit. Going from novice to beginner means increasing your skill level to the point that you can complete some tasks.
An intermediate is someone who can do more than an a beginner. To go from beginner to intermediate, you build on your foundation. Wait, what foundation? What skills do you already have? What did you learn when going from novice to beginner?
We don't know. This is the huge difference between novice -> beginner and beginner -> intermediate. The second transformation has dependencies.
There are solutions to this that aren't hard. When you run into an unmet dependency (the author assumes you know something you don't) backtrack and learn it. This works in theory and usually fails in the real world.
Most people hate unmet dependencies of knowledge. Hate hate hate it. They make them feel dumb and people hate feeling dumb. (You are most likely this way and don't realize it. If not, you have a strength and you should be using it).
I believe this is the problem that traditional learning solves (a bit) and independent learning does not. You can rant about how much colleges suck (I do sometimes) but they provide a few important things for real people learning: A track meant to avoid unmet dependencies, some amount of resources to backfill unmet dependencies, and social pressure to stick through it even when you hate it.
I'm learning Go (relearning, I learned it when it first came out but never used it) and came across something like this:
type Record struct {
Name string `json:"name"`
}
This is what intermediate-to-advanced material can do to really help out, especially for people who want to see real world use-cases and for one reason or another don't want to or haven't fully gone through all the basic material (or just forgot parts of it).
I believe there's also a factor that intermediate knowledge requires much more of a conceptual grasp. Selecting or joining on the correct columns is one thing, but actually knowing when to use what operation and which might have better performance means you need an intuition about the data structures. This is much harder to teach, and probably the only really good way is to get people to attack lots of problems set at the right level of challenge.