Declarative Programming with Prolog – Part 3: Putting it All Together


Table of Contents

  • Part 1 – Getting Started
  • Part 2 – Unification, Recursion, and Lists
  • Part 3 – Putting it All Together

Welcome back to the final post in this Prolog series! If you haven’t done so already, please check out the first two posts before starting this one – or else it may not make much sense. Today, we’re gonna take what we’ve learned so far and build a real live application to showcase how powerful Prolog can be. We’ll be building a sudoku solver, which will be a Prolog script that accepts an unfinished grid and will solve the rest of it on its own. Here’s the crazy part: did you know you can do this in just 15 lines of Prolog? We’ll be showing that minified script later in this post after we go over a simpler way to build our solver, as well as other powerful ways that you can use Prolog. You’ve come this far in the series – let’s finish strong!

What We’re Gonna Build

Unfinished Sudoku GridWe’re gonna be building a sudoku solver, and just to make sure we’re all on the same page, let’s briefly review how the game of sudoku works. In sudoku, you’re provided an unfinished 9×9 grid that you have to complete, and each cell must be a number between 1 and 9. The catch is that each row, cell, and 3×3 square of the grid must contain the numbers 1 through 9 and they must be unique (e.g. you can’t have the number 1 twice in the same row).

For the duration of this post, we’ll be building a script that solves a 4×4 sudoku grid, instead of a 9×9. The concepts will all be the same – but the smaller the grid size, the easier it will be to both explain and to grasp the concepts.

The Full Script

Before we get deep into solving this problem – I want to share the full Prolog script as well as the query we’ll be using:

Note: I take zero credit for this code; it comes from the Pragmatic Bookshelf book: 7 Languages in 7 weeks (although it was slightly modified to work with SWI-prolog instead of GNU Prolog).

And our query:

Our solved sudoku board will get unified to the Solution variable, which will print out when we run this query. Even without a deep explanation – if you look at this script for a minute, you can probably grasp most of the concepts; don’t worry though, we’ll still explain everything!

Building Our 4×4 Sudoku Solver

First off, we need to include the clpfd module because we’ll be using a couple of pre-defined predicates in our script. I’ll bring attention to these when we use them.

Next, we start off our sudoku rule which accepts a list with a length of 16 (i.e. our unfinished sudoku board), as well as a variable which we’ll unify to our solution:

We then unify our Solution to our list, and then further unify our list into 16 other variables – one to represent each cell:

This next line is our first predicate from the clpfd module that we’ll be using: ins. This tells our Puzzle variable that we only want to set its entries to values between 1 and 4 – and since our Puzzle variable was unified to the 16 variables representing each cell, this logic caries over to those variables as well.

The next 14 lines are just more unifications. We’re creating variables to represent each row, column, and square, and setting them each equal to a list with a length of 4 to represent their cells.

So far all we’ve done is some simple unification; we haven’t written any actual logic that tells Prolog how the rules of sudoku work. Well, believe it or not, that’s the easiest part! That’ll only take 6 lines to accomplish, and it will complete our script:

Here in the final subgoal of the sudoku rule, we’re querying another predicate (the valid predicate) and passing in a list containing each row, column, and square. Now we need to define what the valid predicate actually entails – but wait, there’s two of them up there! Yup – that’s because we’ll be using recursion similarly to how we did in the last post.

Here’s a list of the actions that take place when we first call the valid predicate:

  • the first valid predicate is called – which is a fact. This is our base case.
  • This fact returns false because the list that was passed in has 12 entries (4 rows, 4 columns, and 4 squares), and the fact is trying to unify it to an empty list – which doesn’t work.
  • Next, the valid rule is called, which immediately splits the passed-in list into a Head variable which contains the first entry in the list (which is the first row), and a Tail variable which contains the remainder of the list (everything but the first row).
  • The first subgoal of the valid rule calls the all_different predicate, which is the other predicate we’re using from the clpdf module. This predicate simply accepts a list as an argument and checks if each entry in the list is unique. Nothing crazy.
  • Our last subgoal of the valid rule is a tail-optimized call back to the valid predicate – BUT – we’re passing in the original list minus its first entry.
  • This process repeats – and each time the stack frame changes, valid is called with one less length.
  • Eventually, after 12 loops, the first valid fact (our base case) will return true because at that point, the list will be empty.
  • This completes the entire query.

After the valid query completes, Prolog will have properly unified our Solution variable to either a valid solution, or it will have determined that a solution wasn’t possible. Let’s see what we get when we issue our query:

We did it! We have a valid solution! And while we only solved a 4×4 grid, these exact same concepts apply if we wanted to solve a 9×9 grid instead.

Why This Is Awesome

We just solved a 4×4 Sudoku grid using Prolog – but if you’re not impressed yet, then you’re bound to be asking something like “I can build this in an imperative language in a similar way – why is this impressive?” Well, think about it. If you wanted to build this logic in an imperative language, then you could certainly create a function that accepted a list of a completed sudoku board and use this same logic to verify that the board was indeed a valid solution – but there’s no way that an imperative language could actually solve the board on its own without a lot of extra logic that either you or some other module would provide. See – this is what makes Prolog (and declarative programming) so powerful; we never told Prolog how to solve the board – we just gave it the rules! We just told it that each row, column, and square had to be unique – and that’s it! It figured everything else out on its own!! You just can’t do this type of thing in imperative languages!

This is the power of unification in Prolog – and if you haven’t understood how it’s fundamentally different from assignment in other languages, then I hope this helped to paint that picture. It’s these types of problems that Prolog is meant to help solve.

Now, I mentioned in the intro that there are sudoku solvers written in 15 lines, and while we won’t be getting into the nitty-gritty of how they work, it’s safe to say that they’re based off of the same concepts that we discussed in our little example above. Here’s a demo of a real sudoku solver in Prolog; this solution also solves the full 9×9 puzzles – not the little 4×4 puzzle we solved above:

And our query:

Bam – look at that!

Taking Prolog a Step Further

Hopefully you’re impressed with Prolog by now – but maybe you’re wondering how you would interact with Prolog from another program. Surely not via issuing command line queries, right? Well, how about an HTTP Server?

Yeah – Prolog can do that too!

Prolog Server Response - Hello World!

Amazing, right?!

The Series Conclusion

There will always be problems that imperative languages can solve better than declarative ones; after all, there’s a reason why they dominate the programming market. But, that doesn’t mean that declarative languages don’t have their place in the programming world – for as you saw throughout this series, you can do some really cool, powerful things with Prolog.

The big takeaway is this: Using Prolog where it’s not meant to be used would be silly – but by using it in a situation where it can really shine, you’ll really turn some developer heads. And regardless of if you ever do use Prolog for fun or in your career – at the very least, I hope this helped broaden your perspective on different programming paradigms by teaching you a little bit about declarative programming.

Thanks for sticking with me this far! Feel free to check out the whole GitHub repo complete with all of the demos that we coded throughout this series.