A Friendly Introduction to Racket

Prolog is one of the two classic languages for symbolic artificial intelligence programming (the other classic language being Lisp). Prolog excels at implementing symbolic rule-based systems in which declarative knowledge is encoded in first-order logic. The language is optimized for expressiveness and efficiency for these types of applications, sometimes at the expense of logical purity. For example, by default Prolog does not use the "occur check" in unification. From a math/logic standpoint, this version of unification is incorrect. However, the occur check is expensive, and in most cases the lack of the occur check is not a problem. This is a very pragmatic design decision, as is Prolog's use of depth-first search, and use of cut (!) to control backtracking. I'm sure these decisions were absolutely necessary when running on the hardware of the 1970s, and today are very useful when working on large problems, and when dealing with huge (often infinite!) search spaces.

Prolog supports many "extra-logical" or "non-logical" features, including cut, assert and retract, projection of variables for arithmetic using is, and so forth. Many of these features make it easier to express complex control flow, and to manipulate Prolog's global database of facts. One very interesting feature of Prolog is that Prolog code is itself stored in the global database of facts, and can be queried against at run time. This makes it trivial to write meta-interpreters that modify the behavior of Prolog code under interpretation. For example, it is possible to encode breadth-first search in Prolog using a meta-interpreter that changes the search order. This is an extremely powerful technique that is not well known outside of the Prolog world. 'The Art of Prolog' describes this technique in detail.

Tremendous effort has gone into improving Prolog implementations, most of which are based on the Warren Abstract Machine (WAM). The WAM uses a side-effecting model in which values are destructively assigned to logic variables, with these side-effects being undone upon backtracking. Many features can be added to Prolog by extending the instructions of the WAM. One disadvantage of this approach is that Prolog implementation papers can be difficult to read without a solid understanding of the WAM. On the other hand, Prolog implementer have a common model for discussing implementation issues. There has been a great deal of research in parallel Prolog, culminating in Andorra Prolog in the 1990s. At least some of these ideas live on in Ciao Prolog. (Ciao Prolog is full of interesting ideas, many of which go far beyond the Prolog standard.)

Prolog has a beautiful unification-based "pattern-matching"-style syntax that results in very succinct programs. Prologers love their syntax, just like Lispers love their s-expressions. Prolog also has a large library of standard predicates. Due to all of the engineering that has gone into making the WAM fast, there are very capable and mature Prolog implementations. As a result, many large knowledge-based systems have been written entirely in Prolog.

So, why do you say that Prolog is a "poor general purpose language"?

r3rs, r4rs & r5rs (section 4.2.6):

https://standards.scheme.org/official/r3rs.pdf

https://standards.scheme.org/official/r4rs.pdf

https://conservatory.scheme.org/schemers/Documents/Standards...

"If a comma appears followed immediately by an at- sign (@), then the following expression must evaluate to a list;"

r6rs (section 11.17):

https://standards.scheme.org/official/r6rs.pdf

"If an (unquote-splicing 〈expression〉 . . . ) form appears inside a〈qq template〉, then the〈expression〉s must evaluate to lists;"

r7rs (4.2.8):

https://standards.scheme.org/official/r7rs.pdf

"If a comma appears followed without intervening whitespace by a commercial at-sign (@), then it is an error if the following expression does not evaluate to a list;"

> So, why do you say that Prolog is a "poor general purpose language"?

Big disclaimer: I have almost no Prolog experience beyond a distant university class, so I've no idea what's possible with a pragmatic impl. like SWI-Prolog. Still, this is my uninformed "Emacs vs vim tier" opinion.

For the same reason as most other people do so: when you're not working with problems suited for it (most of them), Prolog loses much of its power and intuitiveness to become a barebones functional PL without much going for it (needing lots of extensions beyond ISO); bit like Erlang outside distributed/high availability situations. The other way is going full "hammer and nails" and try to hamfist every problem into a logic/declarative one.