My Gripes with Prolog

Summary

For the next release of Logic for Programmers, I'm finally adding the sections on Answer Set Programming and Logic Constraint Programming that I TODOd back in version 0.9. And this is making me re-experience some of my pain points with Prolog, which I will gripe about now. If you want to know more about why Prolog is cool instead, go here or here or here or here. No standardized strings ISO "strings" are just atoms or lists of single-character atoms (or lists of integer character codes). The various implementations of Prolog add custom string operators but they are not cross compatible, so code written with strings in SWI-Prolog will not work in Scryer Prolog. No functions Code logic is expressed entirely in rules, predicates which return true or false for certain values. For example if you wanted to get the length of a Prolog list, you write this: ?- length([a, b, c], Len). Len = 3. Now this is pretty cool in that it allows bidirectionality, or running predicates "in reverse". To generate lists of length 3, you can write length(L, 3). But it also means that if you want to get the length a list plus one, you can't do that in one expression, you have to write length(List, Out), X is Out+1. For a while I thought no functions was necessary evil for bidirectionality, but then I discovered Picat has functions and works just fine. That by itself is a reason for me to prefer Picat for my LP needs. (Bidirectionality is a killer feature of Prolog, so it's a shame I so rarely run into situations that use it.) No standardized collection types besides lists Aside from atoms (abc) and numbers, there are two data types: Linked lists like [a,b,c,d]. Compound terms like dog(rex, poodle), which seem like record types but are actually tuples. You can even convert compound terms to linked lists with =..: ?- L =.. [a, b, c]. L = a(b, c). ?- a(b, c(c)) =.. L. L = [a, b, c(c)]. There's no proper key-value maps or even struct types. Again, this is something that individual distributions c...