Prolog is exceptionally well suited for solving such combinatorial puzzles, and of course also for much tougher tasks like timetabling instances in schools, workforce rosters, tournament schedules etc.
The key feature that makes Prolog so attractive for such tasks is the availability of constraint solvers that ship with many Prolog systems and which can be used to elegantly express these tasks in terms of relations between integers, Boolean variables, rational numbers and other domains. The sophistication and efficiency of constraint solvers depend heavily on the used Prolog system, and fast constraint solvers are often an important motivation for buying a commercial Prolog system such as SICStus Prolog.
Interestingly, constraint solvers can themselves be implemented elegantly and efficiently in Prolog too. See for example A Pearl on SAT Solving in Prolog by Howe and King, where the authors use Prolog and its delay declarations to implement a succinct SAT solver with watched literals and unit propagation:
I'm curious how solvers in commercial Prolog systems compare to the family of MiniZinc solvers, like Google's OR-Tools or GECode.
There are plenty of examples of Sudoku models in MiniZinc, and models for many other combinatorial problems as well.
Yes, it is easy to express simple tasks like Sudoku in MiniZinc. However, in terms of sophistication and convenience, Prolog is hard to beat, since it is a full-fledged programming language that can also be used to fetch, process and transform any available input in any way necessary to make it amenable to all built-in constraint solvers.
Compared to a Prolog program, a MiniZinc model is quite hard to parse and reason about programmatically: Every Prolog program is also a valid Prolog term, and can be reasoned about logically as long as we keep to the pure monotonic core of Prolog, which also includes constraints. Pure Prolog programs can be debugged declaratively by generalizing away goals, whereas for example removing a line of a MiniZinc model may render the model invalid.
In addition, Prolog provides logic variables and therefore allows interesting questions to be asked about the model, such as queries about partially known data. This, in combination with Prolog being a programming language, allows its application in a way that is not readily available, or may not be possible at all, with more special-purpose tools and modeling languages. For instance, David C. Norris is using Scryer Prolog and its integer constraints to model and analyse dose escalation trials as they arise in clinical oncology, exceeding the expressiveness of other modeling languages:
https://github.com/dcnorris/precautionary
Regarding sophistication, a good example are dedicated placement constraints of SICStus Prolog such as the geost/N family of constraints:
https://sicstus.sics.se/sicstus/docs/latest4/html/sicstus.ht...
The publication A Geometric Constraint over k-Dimensional Objects and Shapes Subject to Business Rules by Carlsson, Beldiceanu and Martin gives an overview of what is going on behind the scenes when these constraints are posted:
http://contraintes.inria.fr/~jmartin/CBM08cp.pdf
Implementing these constraints with the efficiency, generality and correctness that SICStus provides is a huge project.
> However, in terms of sophistication and convenience, Prolog is hard to beat, since it is a full-fledged programming language that can also be used to fetch, process and transform any available input in any way necessary to make it amenable to all built-in constraint solvers.
Surely the same thing could be accomplished in Lisp as well?
If you'd like to see how to do that yourself: https://github.com/norvig/paip-lisp