2 ms·

Is it your contention that the author doesn't understand that that Prolog predicates don't "return" anything, that they were expecting assignment rather than un

Is it your contention that the author doesn't understand that that Prolog predicates don't "return" anything, that they were expecting assignment rather than unification? I would read it again, their examples clearly state these (noting that the author does say "return", but also clearly shows bidirectional examples). Both you and GP have had some fairly strong responses to what looked like mild complaints, the kind I would expect anyone to have with a language they've used enough to find edges to.

YeGoblynQueenne 9mo ago
See this: The original example in the last section was this: foo(A, B) :- \+ (A = B), A = 1, B = 2. foo(1, 2) returns true, so you'd expect f(A, B) to return A=1, B=2. But it returns false. foo(A,B) fails because \+(A = B) fails, because A = B succeeds. That's because = is not an assignment but a unification, and in the query foo(A,B), A and B are variables, so they always unify. In fact here I'm not sure whether the author expects = to work as an assignment or an equality. In \+(A = B) they seem to expect it to work as an equality, but in A = 1, B = 2, they seem to expect it to work as an assignment. It is neither. I appreciate unification is confusing and takes effort to get one's head around, but note that the author is selling a book titled LOGIC FOR PROGR∀MMERS (in small caps) so they should really try to understand what the damn heck this logic programming stuff is all about. The book is $30.
- dwattttt 9mo ago
  The author also wrote in the same article: > This is also why you can't just write A = B+1: that unifies A with the compound term +(B, 1)
  - YeGoblynQueenne 9mo ago
    Yes, and then they were horribly confused about why foo(A,B) fails, regardless. They clearly have heard of unification and find it a fascinating concept but have no idea what it means. Honestly, we don't have to wrap everyone on the internets in a fuzzy warm cocoon of acceptance. Sometimes people talk bullshit. If they're open to learn, that's great, but the author is snarkily dismissing any criticism, so they can stew in their ignorance as far as I am concerned. Like the OP says, the author didn't bother to RTFM before griping.

YeGoblynQueenne 9mo ago

See this: The original example in the last section was this: foo(A, B) :- \+ (A = B), A = 1, B = 2. foo(1, 2) returns true, so you'd expect f(A, B) to return A=1, B=2. But it returns false. foo(A,B) fails because \+(A = B) fails, because A = B succeeds. That's because = is not an assignment but a unification, and in the query foo(A,B), A and B are variables, so they always unify. In fact here I'm not sure whether the author expects = to work as an assignment or an equality. In \+(A = B) they seem to expect it to work as an equality, but in A = 1, B = 2, they seem to expect it to work as an assignment. It is neither. I appreciate unification is confusing and takes effort to get one's head around, but note that the author is selling a book titled LOGIC FOR PROGR∀MMERS (in small caps) so they should really try to understand what the damn heck this logic programming stuff is all about. The book is $30.

dwattttt 9mo ago
The author also wrote in the same article: > This is also why you can't just write A = B+1: that unifies A with the compound term +(B, 1)
- YeGoblynQueenne 9mo ago
  Yes, and then they were horribly confused about why foo(A,B) fails, regardless. They clearly have heard of unification and find it a fascinating concept but have no idea what it means. Honestly, we don't have to wrap everyone on the internets in a fuzzy warm cocoon of acceptance. Sometimes people talk bullshit. If they're open to learn, that's great, but the author is snarkily dismissing any criticism, so they can stew in their ignorance as far as I am concerned. Like the OP says, the author didn't bother to RTFM before griping.