Unlike usgroup I don't think I can be very encouraging. It is very hard to learn Prolog if you approach it as a programming language rather than an implementati

Unlike usgroup I don't think I can be very encouraging. It is very hard to learn Prolog if you approach it as a programming language rather than an implementation of the Resolution-based logic programming paradigm. I coded in Prolog for many years and I was reasonably proficient in it, but I only really understood it during my PhD when I finally had the time to study logic programming textbooks and understand where it comes from. Unfortunately, that is simply not the amount of time that one has unless one is doing a PhD -and one in a relevant subject, as I did. As a for instance, \=/2 is not "not equal", but "does not unify". So for example A \= B is false, because A and B are variables and unify, a \= b is true because a does not unify with b and a \= B is false again because a unifies with B (as in a = B... which is not equality, or assignment, but unification). I'm guessing that your trouble with pattern matching (i.e. unification) of lists comes from the same place. All this will inevitably and understandably sound downright weird unless you know why unification exists. But that means you need to understand Resolution, and logic programming. Regarding (2), indeed, Prolog predicates are relations, not functions. It might help to think of the er relation between a function, and a relation. Say for example the addition function: x + y = z; or, in Polish ish notation: +(x,y) = z. If you wrote that as a relation: +(x,y,z). Meaning you _could_ see a relation as a function with just one extra argument that holds the return value of the function. If you have trouble transposing the function-like representation of code in your head to a relational one, for Prolog, try doing it that way. Instead of trying to write functions that are replaced by their return values, write functions+return that have one extra variable for the return. So, sort(List) = Sorted becomes sort(List,Sorted). reverse(List) = Reverse, becomes reverse(List,Reversed) and so on. Ingore for a moment the usual comment about how Prolog predicates do not have "return" variables, only terms in some relation. True, but if it's blocking you, avoid thinking about it. Until you can think about it. Btw, the reason that Prolog predicates aren't replaced by their value, not even their truth value, is that Prolog inherits its semantics from First Order Logic (FOL), where there's also no replacement of values. In fact, FOL _has_ functions, but they, too, are not the kind that is replaced by their value. I think that kind of function is only found in programming languages and then not all of them either. The reason for (3) also has to do with Resolution and how it is most efficiently implemented. There are alternatives, e.g. datalog, or Answer Set Programming, which are more purely logical; or Prolog with tabling, a.k.a. SLG-Resolution, which doesn't suffer from left-recursion (what you get when you put a recursive literal first in the body of a clause). >> Because even a Prolog genius would probably admit that there is no point in trying to implement anything IO with it. I'm no Prolog genious, so what does "anything IO" mean?