Perusing Prolog (Part 2)

In interview style, here’s the conclusion of my reflections after studying Prolog for two months. If you’d like, read Part 1 first.

What did you find unique about the language?

Unification! Prolog works by trying to make terms equal one another. In most languages, the statement “Cost = 100” sets the variable “Cost” to a value of 100. In Prolog, “Cost = 100” means (in effect): “can Cost and 100 be unified?” During execution, Prolog takes into account the entire set of logical rules that have been defined to figure out if Cost and 100 are allowed to equal the same value. While possible, the need for statements manipulating variables’ values within an operation occurs far less frequently in Prolog than in the languages I’m used to.

Prolog doesn’t use functions! Whether it’s called a method, procedure, sub-routine, or something else, functions are core building blocks in the programming languages I typically work with. Loosely speaking, a function takes input(s), computes and then returns output. A method combining two lists into a single list might be defined as “append(List1, List2)” and be invoked something like “var completeList = append(partialList1, partialList2)”. Its body would contain step-by-step instructions telling the computer how to take two lists and combine them.

Prolog’s core unit of reusable code is the predicate. Usually, this construct takes several variables which Prolog attempts to unify using the predicate’s rules. Unlike our functional example, the rules inside the predicate are not step-by-step instructions; rather, they define how the given variables may be unified.

In Prolog, append might be defined as “append(List1, List2, CombinedList)”. Calling “append([1,2], [3,4], Output)” will unify the variable Output to [1,2,3,4]. At first glance, this may look rather like our functional example: two values were passed in and one passed back out. However, there’s no requirement that the first two variables must be passed in or that the third one needs to be the value passed out. We can pass in any combination of variables and values. Prolog will unify them, if possible.

Call “append([1,2], X, [1,2,3,4])” and Prolog will unify X to [3,4]. Calling “append(X, Y, [1,2,3,4])” allows us to fetch the complete set of X/Y combinations that can be unified to equal [1,2,3,4] (for example: X=[], Y=[1,2,3,4]; X=[1], Y=[2,3,4]; X=[1,2], Y=[3,4]; etc.). The call to “append([1,2], [3], [1,2,3,4])” fails because append’s rules do not allow [1,2] and [3] to be unified to [1,2,3,4].

How do you expect your Prolog studies to benefit you going forward?

The paradigms studying Prolog pushed me to wrap my mind around will carry over to my work in other programming languages. When I contemplate how to implement a certain requirement in one of the languages I regularly work with, I’ll be able to draw on the concepts I picked up from Prolog.

When architecting solutions, the familiarity I’ve gained with the logic programming language Prolog will allow me to evaluate whether that specific language or that general category of languages should be considered as a possible tool of choice. Previously, I had no exposure to logic programming languages and so had no basis to evaluate their applicability.

I hope I’ll find occasion to use Prolog professionally, perhaps as a component in a system I build. Whether or not that opportunity comes, I’ve benefited by the broader mindset studying Prolog has given me.

Leave a Reply

Your email address will not be published. Required fields are marked *