Map colouring tasks such as shown in the article are indeed an excellent fit for Prolog. The key to efficient formulations of such combinatorial tasks is to avoid generating all possibilities by pruning the search space as early as possible.
It is a major attraction of Prolog that both pruning and search are performed implicitly via constraint propagation and backtracking, respectively.
For example, if we write, for the example predicate neighbor/2 in the article:
neighbor(A, B) :-
dif(A, B).
then we can flexibly move the actual enumeration either before or after posting the constraints, and it is the latter that yields especially efficient solutions.
The key to this are declarative predicates like dif/2 and (#\=)/2 (for the special case of disequality over integers), which act as true relations also if their arguments are not yet fully instantiated. A key characteristic of logic programming languages like Prolog is their ability to reason about actual variables, i.e., terms that stand for "anything at all". The enumeration of "terms" in the article should ideally mention this important case too.
Recognizing that template resolution in C++ is basically logic programming helps when debugging type errors in templates. Merely reformatting the types and errors to look more Prolog-y helped me immensely when dealing with a heavily templatizd library for matrix programming: https://www.boost.org/doc/libs/1_67_0/libs/numeric/ublas/doc...
I dislike negatively reviewing an article, but the assertion is misleading. All C++ is doing in this case is type deduction, and that is basically unification.
Sure, this is a very narrow subset of logic programming. But that would be like saying you can do variable assignment in logic programming so logic programming incorporates C++. The things that make LP strong (in particular recursion) is not handled in any way here.
If I'm not mistaken, this is basically template metaprogramming, and you're going to get your answers at compile-time (which means your inputs are also locked-in at compile-time). For applications that, for example, get the countries and/or colors from a user or database at runtime, wouldn't it be better to use a constraint solver library instead?
Is there any good logic programming course I could follow online? I have looked but it's hard to judge quality when I don't have any experience with logic programming.
Map colouring tasks such as shown in the article are indeed an excellent fit for Prolog. The key to efficient formulations of such combinatorial tasks is to avoid generating all possibilities by pruning the search space as early as possible.
It is a major attraction of Prolog that both pruning and search are performed implicitly via constraint propagation and backtracking, respectively.
For example, if we write, for the example predicate neighbor/2 in the article:
then we can flexibly move the actual enumeration either before or after posting the constraints, and it is the latter that yields especially efficient solutions.The key to this are declarative predicates like dif/2 and (#\=)/2 (for the special case of disequality over integers), which act as true relations also if their arguments are not yet fully instantiated. A key characteristic of logic programming languages like Prolog is their ability to reason about actual variables, i.e., terms that stand for "anything at all". The enumeration of "terms" in the article should ideally mention this important case too.
Sure, this is a very narrow subset of logic programming. But that would be like saying you can do variable assignment in logic programming so logic programming incorporates C++. The things that make LP strong (in particular recursion) is not handled in any way here.
https://mitpress.mit.edu/books/art-prolog-second-edition
Beware that the 2nd edition has some typos.
It's somewhat old but I was able to do everything in the course with SWI-Prolog just fine -- turns out not much is changing in Prolog-land.