The problem you may have met is that you had written a fact such as this:
Now, suppose you also had
is_at( fred, b ). is_at( dragon, a ).then the question
will_be_burnt_alive( fred ).would give the answer ``Yes''.
But if you had had
is_at( fred, a ). is_at( dragon, b ).then the same question would have been answered ``No'', despite the fact that the two caves are connected. This is because Prolog doesn't know that
meetsis two-way: as explained at the end of Lesson 1, it doesn't know that, if A meets B, then B necessarily meets A.
To get round this, you might think of adding the fact
This is certainly correct, logically speaking. Unfortunately, Prolog is not a complete implementation of logic, and you can't expect that, just because a program makes logical sense, Prolog will necessarily be able to run it. In fact, as some of you have already found, adding a fact like this is likely to get Prolog into an infinite loop. If you wonder why this should be, the stuff on execution order in a later lesson will give you a clue. Should you now be worrying that you now can't rely on Prolog at all, relax! Most of the exercises I set will run quite happily, and when I think they might not, I'll give you ample warning.
The standard way round the difficulty above
is to define a new predicate
joins, or some other suitable
Then, whenever you want to talk about one cave joining another, use
joins and not
will_be_burnt_alive( fred ) :- is_at( fred, P ), is_at( dragon, D ), joins( P, D ).Always using
joinsin your other definitions will get rid of the problem, and provide you with a safely symmetrical version of
meets. If you hadn't done something like that already, try it now.
Incidentally, don't be thrown by my use of multi-letter variables
Cave2 in the two facts for
joins. Variables can have any
number of letters, as long as they start with an upper-case one. I just
wanted something more meaningful than