Back in 2005, while working in large-scale programming projects for data-mining in G.I.S. and Hydrology, I wrote a Prolog interpreter called “G.I.S. Prolog“, equipped with many extra predicates (such as functions to locate points inside polygons, etc).The G.I.S. Prolog interpreter was originally based on the “PIE interpreter” (included as free source-code in Visual Prolog) but it ended up enhanced with many extra predicates, as well as an improved core-level inference mechanism.

Ever since I started using the Visual Prologcompilers (and the PDC Prolog compilers preceding them) I was fascinated by the possibilities of implementing additional ISO-Prolog functionality in Visual Prologthrough Assembly Language and ‘C’. Of course, such attempts are inherently limited by the internal design of Visual Prolog compilers. So, the only way to implement ISO-Prolog functionality in Visual Prologis to extend the “PIE Interpreter” (and G.I.S. Prolog as its offspring). A multitude of extra predicates, implemented in pure Assembly language, became available through G.I.S. Prolog for easy immediate experimentation: Coding in G.I.S. Prolog produced immediate results, without any need for (often tedious) EXE-file compilation. Code modifications could therefore be done very quickly and most mistakes were (semi-)automatically corrected by the interpreter’s own enhanced error-checking capabilities.

Recently, I discovered some Assembly language techniques to enhance G.I.S. Prolog even further, potentially valuable for a multitude of other purposes. They also have an intrinsic fascination in themselves, as general tools for Prolog meta-programming.

E.g. here is an Assembly language predicate, that takes as inputs another (external) predicate’s memory-address and a (Visual Prolog-) argument-list, and calls this (external) predicate, using the (arbitrary-length-) list of N arguments, as arguments of “arity N”:apply_func(PRED, [Arg,Arg2,…]) <=> PRED(Arg1,Arg2,…)

Now, in ISO-Prolog there is a standard predicate known as “univ”, written as “=..“, which turns a list like [PRED,ARG1,ARG2,ARG3…] into a predicate call such as PRED(ARG1,ARG2,…). However, this does not exist in Visual Prolog, which sacrifices such “luxuries” for speed (which is the reason I also often use ISO-Prolog compilers, such as LPA-WinProlog and SWI-Prolog).

Anyway… The code you are about to see can be useful more generally, as an example of Prolog meta-programming, implemented in Assembly Language. The only difference between the way it works for Visual Prolog and the way it might work for another Prolog (or -indeed- ANY programming language, using a ‘C’-calling convention) is the Visual-Prolog-specific structure of a LIST, which in Visual Prolog has a different form than in all other languages. If you understand Assembly Language and intend to use this code for other (meta-programming) tasks, all you have to do is modify just a couple of lines in the code that follows. However, before you (even begin to) look at the Assembly Language Code, the following simple definitions in Visual Prolog (5.*) are a prerequisite for easier understanding:

A not-so-obvious advantage of this code is that any Prolog interpeters written on the basis of Visual Prolog’s “PIE engine” (such as G.I.S. Prolog) make extensive use of calls such as this, inside their inference engine; using Prolog-lists of arguments to be called by turning them into proper predicate calls of arity=N (where N is the size of the list). So, an Assembly language implementation of such a calling mechanism can speed up such an interpreter considerably, especially inside recursive calls or loops, which call other predicates repeatedly countless times…

Another not-so-obvious advantage is that -in this way- we managed to… trick Visual Prolog into doing “forbidden” predicate calls, such as PRED(arg1,arg2,….), where both the predicate’s functor and the arguments may appear as static data, stored in a Visual Prolog facts’ database.

Don’t ask me (yet) how to implement such tricks in Visual Prolog 6.* or 7.*; I still use the version 5.* compilers a lot, because of their speed, as well as robustness in foreign language calls.