Once we have loaded our syntactically correct program and tried it out we may realise that things aren't the way we want. We may come to realise that we did not (informally) specify the problem correctly or that we must have coded the specification wrongly.
We may come to realise that we have an error in our code through executing some query which produces an unexpected result. We regard such evidence as a symptom description. The kinds of symptom description that may result include:
There is also the possibility of unexpected side-effects (or an unexpected failure to produce a side-effect).
Different strategies exist for pinning down the cause(s) of these symptoms. We will not give a complete account here ---just sketch in ways in which the tracer can be used.
The idea of using the tracer is to unpack the program's response to the query which produced a symptom description. This is done by examining the program's behaviour in the hope that we can track down subcomponents which `misbehave'. Hence we search for a program misbehaviour description. Once this has been found we then need to track the fault to an error in the code and generate a program code error description. Finally, underlying the error in the code may be a number of misunderstandings about the way Prolog executes a program, the generality of the code written and so on. Tracking this down would produce a misconception description.