After more than two decades of happy programming in Prolog (and only a few less years in Assembly Language) it seems natural (or even inevitable!) to create a Blog about all this.
I hope to include in this blog as much source-code as possible, with meticulous emphasis on detail, depth, deep analysis and useful tips.
Unfortunately Prolog compilers -even today- have a great number of differences between them, despite the existence of the (so-called) “ISO-Prolog standard“. Very popular, useful and effective Prolog compilers (such as Visual Prolog) have either departed completely from ISO-orthodoxy (adopting features that violate it) or else they tend to provide many features and new commands that don’t exist in any other rival (Prolog compiler).
The latter is true even among “Edinburgh compatible” ISO-Prolog implementations (both commercial and free or open-source); not even one of them is without such extra features. So, if you have moved from one Prolog compiler to another (in your quest for A.I. Coder’s Enlightenment) you know how tedious and troublesome it can be to convert code originally written for one compiler, for successful running in another Prolog compiler (or CLP, or Mercury, Life… and several other languages, Logic Programming cousins of Prolog).
E.g. both SWI-Prolog (one of the best Open Source implementations) and LPA Win-Prolog (one of the most beautiful commercial implementations) implement a respectable ISO-Prolog standard, but both of them include other features (not required by the ISO-specification) that are unique to each one of then, as well as extremely attractive. (Sometimes I wonder how can I cope without then). These superb features are uniquely implemented in only one of them, at a time. (Unfortunately, you can’t use both…)
Finally, this blog is not just about Prolog and A.I. but also about Assembly Language programming (unless I end up… starting a new blog dedicated for Assembler). In my many years of experience in Prolog programming, I have often stumbled on problems of speed. Oh yes, even today, in certain types of CPU-speed-intensive applications. Apart from the usual algorithmic optimisations, only Pure Assembly Language can offer serious speed improvements (typically of at least one order of magnitude).
Serious massive data-mining tasks, do require a lot of Assembly Language optimisations, even today (at a time where today’s CPU speeds are mature and quite phenomenal). This was also the topic of a paper I presented, at the ALP Visual Prolog programming conference in Portugal (in April 2006 – click here to read the paper – about “Assemby Language Optimisations of Prolog”).
