I’m just starting out with Prolog. Have played a little bit with GNU Prolog and look now for Prolog resources (books, forums, etc). There is a lot on the Internet, so it overwhelms a bit and many sites are pretty old (which in itself is not necessarily means that they are outdated).
However, I found the online book The Power of Prolog which attracts me because it looks reasonably recent…
Through this I got to the implementation Scryer Prolog. So maybe that’s better for beginners than GNU Prolog? And of course there is SWI Prolog as well…
Any tips what are good resources and a good implementation for a newbie?
I had a quick look at the LPN website and the text background always shows on all pages the pretty irritating large words “Testing version”. Is there a URL which shows the book without this background?
The original is at Learn Prolog Now!. http://lpn.swi-prolog.org is a proxy server that rewrites the pages on the fly to embed SWISH inline. When this was done we settled for this warning. The embedded version is a nice idea, but the HTML of the original makes it raher hard to properly identify source code and examples. Ideally the source should be annotated such that the proxy doesn’t have to guess what is what. Better might be to reformat the material in Spinx-Prolog for creating interactive Prolog books
I think if your concern is portability – its my experience that the iso standard alone will likely not help you – if you are looking to create a larger code base, since you will end up using libraries and features that will limit portability.
If this is a real concern for you then I would suggest to look at Logtalk – which is a object-oriented extension of Prolog with a key design goal of portability in mind.
The OO extension supports many prolog “backend” compilers including swi-prolog and, more recently, Scryler prolog as well .
The price one pays is a somewhat more complex development setup / environment, somewhat longer compile time, a possible, small performance overhead, and, in my opinion, a debug experience that is less optimal – given that OO extensions are implemented as expansions – which show through during debugging.
But, if portability is a key objective – then its a great tool for that.
And, its a tool that better supports software engineering principles such as information hiding, inheritance and more – in a portable way.
The whole chars/codes debate was a big pain in the * while establishing the ISO standard. In the end ISO decided to support both models and as the then dominant Prolog systems such as Quintus used the code model that became the de-facto default in SICStus, SWI, YAP, Ciao and many more.
Personally I don’t care too much. The main problem is that the two models poorly mix. Often you can use the same source in both modes. It part of your program uses chars and other parts codes they cannot use the same library though. Also some things to not work. How to you express a character in the range a to z using chars? Using codes it is as simple as between(0'a,0'z,C). Using chars you need to use char_code/2. While DCGs can often run in both modes, low level character manipulation is different where the codes version is a bit more flexible as using a char you can only test identity with some other char while you can sometimes do meaningful arithmetic on character codes. For example a digit weight can be expressed as W is C-0'0. SWI-Prolog has char_type/2 to do a lot of category checking, digit weight and some more, but this is not a standard predicate.
The big advantage of the char model is that it makes working with DCGs on characters more natural. That barely affects real applications, but it does affect small teaching examples and to some extend debugging (although portray_text/1 solves most of the debugging issues). Another disadvantage is that control characters get printed literally by write/1, which may upset your terminal (quoted write will use e.g., '\r'). Finally there is the cost of atoms. With 128 ASCII chars this is neglectable and we can add them to the system built-in (locked) atoms. With all the Unicode characters you don’t want to create them upfront. As a result they are created on the fly and subject to atom garbage collection. A long list of Unicode chars is a lot more work for the atom garbage collector than a long list of (still) small integers.
A nice feature of Scryer Prolog is that it can handle native character arrays transparently as lists. This (if I understood correctly) allows for example to map a text file into memory and use it as a list without ever materializing the list. I don’t know what price they pay in terms of performance as I guess this means some runtime checking everywhere lists are used. Its also unclear what the benefits are compared to phrase_from_file/3 which uses the lazy list approach. That also gives overhead. The reward is that it allows running DCGs on infinite streams such as a socket stream.
I think a key contribution of logtalk is to sort out across the many prolog variants what can be supported though one wrapper system (and libraries) – and how far can this be taken.
Iso standard is likely a big help in getting agreement, including semantic agreement, for a core, while, likely many more issues were sorting out as well – a key value in its own right.
Ultimately, you get a common subset of all … that is portable.
And you can also decide what you keep portable and when you “drop back” to features of a specific backend.
Although a bit dated, you find why not at 
(quoted write will use e.g., 