1

I think that I think that I am doing a little confusion with the declarative view of not predicate in Prolog.

I have that I can implement not predicate simply in this way:

not(P) :- P, !, fail;
          true.

where P it is a predicate and not P is FALSE if P it is TRUE and TRUE if P it is false.

Reading on the Bratko book I can read:

If Goal succeeds then not(Goal) fails, otherwise not(Goal) succeeds

Ok maybe I am doing to much problem trying to interpret this code snippet but seems me that this goes beyond the declarative paradigm and the logic and go into some kind of procedural paradigm

It seems to me that is a form of if{} else{} implementing by the cut and the fail predicate predicate...I read it in this way:

P is a boolean predicate that can only be: TRUE or FALSE

IF P is TRUE then forces to fail (so it is that not(P) is FALSE) and avoid backtracking to not have other responses.

ELSE P is FALSE and not P is TRUE.

I don't know if my interpretation is wrong, if I am missing something in the reasoning or if I am doing to much problem with stupids questions...

false
  • 10,264
  • 13
  • 101
  • 209
AndreaNobili
  • 40,955
  • 107
  • 324
  • 596
  • 5
    Since you asked [a very similar question yesterday](http://stackoverflow.com/q/15883938/487781), for which you accepted an Answer, perhaps it's time to stop and take stock of your understanding. Your "procedural" interpretation of **not/1** or **\+/1** (ISO) metapredicates seems correct and unexceptional. You quote from Bratko. Yes, it can be derived as a form of if-then-else programming. There is a reason negation-as-failure is implemented rather than trying to provide a purely logical negation semantic. Please narrow down what more you really want answered. – hardmath Apr 09 '13 at 16:41
  • 1
    @hardmath: I already tried this several times, but he ignores it. Sometimes I flag, but it is hopeless. – false Apr 09 '13 at 18:27
  • 2
    We could close as exact duplicate. – Daniel Lyons Apr 09 '13 at 18:30
  • @false: My guess is they don't quite know what Question they want to ask. Perhaps a discussion of Horn clause logic and decidabilty would at least move the doubts into deeper water... – hardmath Apr 09 '13 at 19:25
  • @hardmath: OTOH, the text is sloppily written; extremely verbose "I think that I think that I" etc. This shows that there is zero effort by the asker. – false Apr 09 '13 at 19:33
  • @false: I'm just saying there's a good question in there to be asked. I touched on it [in this old thread](http://stackoverflow.com/q/6332539/487781), and perhaps you've had occasion to connect the dots between Horn logic and Prolog in one of your answers. Just pointing out there's some depth to "negation-as-failure" as an implementation design. – hardmath Apr 09 '13 at 19:38
  • 1
    @hardmath: We know that there is some good core in each question. But will **anybody** needing similar advice will ever conclude this from the question? – false Apr 09 '13 at 19:48

1 Answers1

4

I don't have much to add to what @hardmath said (+1) but it will take me more words to say it so it isn't a comment.

First, you're seeing a hard dichotomy between procedural and declarative, but there are other ways of looking at things and lots of things sit sort of in the middle. \+ is one of them, because it has a mostly-declarative reading, but where the declarative reading falls short has to do with it being executed on a machine. But all of Prolog is executed on a machine, and it doesn't mean that you're never able to think declaratively. It's not an all-or-nothing proposition. The so-called extralogical or meta predicates setof/3 et. al. furnish you with results that are not, strictly speaking, first order logic, but that doesn't mean they're procedural or even necessarily that they're implemented in an overtly procedural way. In short: there are more things than "procedural" and "declarative" in the universe, and it isn't always cut and dry which are which.

Second, you insist on reading conditional logic as inherently procedural. I think this is a fixation on a low-level detail. Yes, you can write Prolog with a lot of red cuts and which only admit a procedural reading, but simply using if/then logic doesn't necessitate that, nor is it a slippery slope from one to the other. You seem fixated on reading "if X then Y else Z" as "First, you do X, then if that succeeds you do Y, or if it failed, then do Z." But you don't have to read it this procedurally, and in fact you probably should not. Even though ordering the conditions affects the performance and sometimes the correctness, you don't need to let it obliterate the declarative reading for you. After all, in any language this will be true to one extent or another, thanks to the halting problem and the fact that we execute programs on machines. If we let that poison our understanding even in Prolog, we'll never be able to escape from it or realize the benefits of declarative programming. In short: if/then/else need not be understood as inherently procedural.

So to sum up: relax. :)

Daniel Lyons
  • 22,421
  • 2
  • 50
  • 77
  • always a good advice. :) although, I'm not sure about this; if the result changes when order of predicates is changed, it is the very definition of procedural code, I think. Also, it is better to *always* read "not" as "can't be proven that ...", which is also procedural. – Will Ness Apr 09 '13 at 17:34
  • If X is red and X is a bird, then X is a cardinal. Yes, on a machine, you will have to try the "red" test first, but that doesn't mean that this is inherently procedural. – Daniel Lyons Apr 09 '13 at 17:35
  • you're missing an else part in your example. what you show is just a conjunction. – Will Ness Apr 09 '13 at 17:36
  • Tnx so much. as usual you are always enlightening – AndreaNobili Apr 09 '13 at 17:36