On Sat, Feb 12, 2022 at 8:37 AM Alexander Burger <a...@software-lab.de> wrote:
> > > > (be + (@A @B @C) > > > (^ @C (+ @A @B)) > > > T ) > > > > > > (be + (@A @B @C) > > > (^ @B (- @C @A)) > > > T ) > > I suppose pilog search for rules in order, so the goal (? (+ 3 @X 7)) > > always matches first three rules with the cut, > > It tries the first one but does not succeed. The second one matches, so the > others are not tried because of the cut. > This is interesting, in my understanding when matching the first rule it should try to unify @C to the result of @A + @B but since @B is @X you have @B unified to a variable or symbol and thus @B is not instantiated, it has no value and so you cannot do the + operation, in my understanding you should have got an exception or an error, in fact this is what you get in prolog: ?- +(3,X,7). Call: (8) +(3, _7186, 7) ? creep Call: (9) 3 is 7-_7186 ? creep ERROR: Arguments are not sufficiently instantiated ERROR: In: ERROR: [9] 3 is 7-_7806 ERROR: [8] +(3,_7832,7) at /prolog_.pl:30 ERROR: [7] <user> I suppose what happens is first rule don't give an error trying to add @A and @B, it simply fails and returns with @C not unified (not binded) and thus the cut is never executed so it tries next rule, the second one, now it succeeds and executes the cut stopping further matching. In this case my question is, what value is binded to @B when passed to lisp function + ? is it nil maybe? or function ^ detects an unbinded pilog variable and just returns with false? > but shouldn't the last goal > > match also one of the first three line thus avoiding backtracking? > > A query like (+ @X @Y 7) will not be satisfied by the first four rules, so finally the fifth fires (and finally terminates recursion with the fourth). > so this is the same case as before, this works because (^ @X (op @A @B)) fails when @A or @B are not binded, being possible to explorer other rule matching regards
