Debugging CHR Programs

## 8.8 Debugging CHR Programs

- Using the Debugger

User-defined constraints including application of CHRs can be traced with the standard debugger. Debugging of the ECLiPSe code is done in the standard way. See the corresponding user manual for more information.

### 8.8.1 Using the Debugger

In order to use the debugging tool, the `debug_compile` flag must have been `on` (default) during compilation (`chr` to `pl`) and loading of the produced ECLiPSe code.

- The query `trace.` activates the standard debugger (tracing user-defined constraints like predicates).
- The query `chr_trace.` activates the standard debugger showing more information about the handling of constraints. (application of CHRs).
- The query `chr_notrace.` stops either debugger.

The debugger displays user-defined constraints and application of CHRs. User-defined constraints are treated as predicates and the information about application of CHRs is displayed without stopping. See the subsection on how CHRs work for an example trace. The additional ports are:

- `add`: A new constraint is added to the constraint store.
- `already_in`: A constraint to be added was already present.

The ports related to application of rules are:

- `try_rule`: A rule is tried.
- `delay_rule`: The last tried rule cannot fire because the guard did not succeed.
- `fire_rule`: The last tried rule fires.

The ports related to labeling are:

- `try_label`: A label_with declaration is checked.
- `delay_label`: The last label_with declaration delays because the guard did not succeed.
- `fire_label`: The last tried label_with declaration succeeds, so the clauses of the associated constraint will be used for built-in labeling.

When displayed, each constraint is labeled with a unique integer identifier. Each rule is labeled with its name as given in the `chr` source using the `@` operator. If a rule does not have a name, it is displayed together with a unique integer identifier.