1% BEGIN LICENSE BLOCK 2% Version: CMPL 1.1 3% 4% The contents of this file are subject to the Cisco-style Mozilla Public 5% License Version 1.1 (the "License"); you may not use this file except 6% in compliance with the License. You may obtain a copy of the License 7% at www.eclipse-clp.org/license. 8% 9% Software distributed under the License is distributed on an "AS IS" 10% basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See 11% the License for the specific language governing rights and limitations 12% under the License. 13% 14% The Original Code is The ECLiPSe Constraint Logic Programming System. 15% The Initial Developer of the Original Code is Cisco Systems, Inc. 16% Portions created by the Initial Developer are 17% Copyright (C) 1995 - 2006 Cisco Systems, Inc. All Rights Reserved. 18% 19% Contributor(s): Thom Fruehwirth & Pascal Brisset, ECRC 20% Kish Shen, IC-Parc 21% 22% END LICENSE BLOCK 23 24% 25% @(#)extchr.tex 1.16 95/05/29 26% Author: Thom Fruehwirth & Pascal Brisset 27% 28% Kish Shen 98/6/29 29% Modified 2002-09-23 30% 31% Deleted sections on Opium (no longer in Eclipse), 32% plus new sections on the new CHR library 33 34\newcommand{\OU}{$|$~} 35 36\newcommand{\rep}{{\tt <=>}\ } 37\newcommand{\aug}{{\tt ==>}\ } 38\newcommand{\rul}{{\tt :-}\ } 39 40 41\chapter{The Constraint Handling Rules Library} 42%HEVEA\cutdef[1]{section} 43\label{chapchr} 44\index{library!chr.pl|(} 45 46%\date{931214} 47 48The {\tt ech} library implements constraint handling rules 49\index{constraint handling rules} (\chrs)\index{CHR@{\sf CHR}}, 50which can be mixed with normal \eclipse code. 51%It includes a compiler, which translates \chr\ programs into 52%\eclipse\ programs, and a runtime system. 53%A second library ({\tt 54%chr_opium.op}) is provided for the debugger which uses Opium, the 55%high-level debugging environment of \eclipse. 56Several constraint handlers are 57provided in example files in the directory {\tt ech}. 58 59This library will replace the older {\tt chr} library. 60In addition, there is now an experimental extended implementation of {\chrs}. 61This extended implementation is faster than the existing {\tt chr} library, 62and contains some extensions and changes. This is described in 63section~\ref{newchr}. 64 65\section{Introduction} 66 67{\em Constraint handling rules} (\chrs, 68CHR home page \ahrefurl{\url{http://www.cs.kuleuven.ac.be/~dtai/projects/CHR/}}) 69\cite{fru92} 70are a high-level language 71extension to write {\em user-defined} constraints. \chrs\ 72consists of guarded rules with multiple heads. 73%embedded in %a given host language (Prolog, Lisp, ML), in this case \eclipse. 74 75The high-level \chrs\ are an excellent tool for {\em rapid prototyping} and 76implementation of constraint handlers. The usual abstract formalism to 77describe a constraint system, i.e. inference rules, rewrite rules, 78sequents, formulas expressing axioms and theorems, can be written as 79\chrs\ in a straightforward way. Starting from this {\em executable 80specification}, the rules can be refined and adapted 81to the specifics of the application. 82 83\chrs\ define {\em simplification} of, and {\em propagation} over, 84user-defined constraints. Simplification replaces constraints by 85simpler constraints while preserving logical equivalence (e.g. {\tt 86X>Y,Y>X 87\rep fail}). Propagation adds new constraints which are logically 88redundant but may cause further simplification (e.g. {\tt X>Y,Y>Z \aug 89X>Z}). Repeatedly applying \chrs\ incrementally simplifies and 90finally solves user-defined constraints (e.g. {\tt A>B,B>C,C>A} 91leads to {\tt fail}). 92 93With multiple heads and propagation rules, 94\chrs\ provide two features which are essential for non-trivial 95constraint handling. 96%and which are not provided by any constraint 97%logic programming language except CHIP \cite{chip}. 98%We can interpret constraints as a computationally efficient incarnation of predicates. 99%Then \chrs\ have a declarative semantics. 100The declarative reading of 101\chrs\ as formulas of first order logic 102allows one to reason about their correctness. On the other hand, 103regarding \chrs\ as a rewrite system on logical formulas allows one to 104reason about their termination and confluence. 105 106 107In the next section 108it is explained how to use \chrs. 109 Then, 110example constraint handlers and the colour graphic 111demo are listed. 112 The next 113section introduces the basics of the \chr\ language and how it works. 114The next section describes more of the \chr\ language, 115the section after the built-in labeling feature. 116Then there is 117a section on how to write good \chr\ programs. Next the debuggers for 118\chrs\ are introduced. 119%Last the Opium scenario for the Opium debugger 120%is described. 121 122 123\section{Using Constraint Handling Rules} 124 125Here are the steps to be taken from writing to using \chrs: 126\begin{itemize} 127 \item Write a \chr\ program in a file 128File\verb/.chr/. 129 130 \item In \eclipse, load the {\tt chr} library with the query 131\verb/lib(chr)/. It contains both the compiler and runtime system for 132\chrs. Now \eclipse\ is in coroutining mode. 133 134 \item Compile your \verb/chr/ file into a \verb/pl/ file with the query 135 \verb/chr2pl(/File\verb/)./ 136 137\item In any \eclipse\ session, you can load a compiled constraint handler 138(\verb/[/File\verb/]./). The \chr\ library is automatically loaded 139to provide the necessary runtime environment. \eclipse\ is in coroutining mode. 140 141\end{itemize} 142You can compile your \verb/chr/ file and load the resulting \verb/pl/ file 143at once using the query \verb/chr(/File\verb/)./ 144 145 146 147\section{Example Constraint Handlers} 148 149All example files are in the subdirectory {\tt lib/chr} of the 150installation-directory of \eclipse\ (which can be found using {\tt 151get\_flag(installation\_directory,Dir)}\index{constraint solvers}. 152The files ({\tt .chr, .pl}, examples) 153relevant to a 154particular constraint system can be found by looking at all files that 155match the pattern given in the following listing with each example 156handler. The examples include a {\em colour graphic demo} about 157optimal sender placement for wire-less devices in buildings and 158company sites, small constraint handlers for 159\begin{itemize} 160%\item n-queens (no\_attack as constraint reduces backtracking), 161\item minimum, maximum of and inequalities between terms ({\tt *minmax*})\index{minmax constraints}, 162\item terms ({\tt functor/3, arg/3, =..} as constraints) ({\tt *term*})\index{term constraints}, 163\item lists (similar to Prolog III) ({\tt *list*})\index{list constraints}, 164\item rational trees ({\tt *tree*})\index{tree constraints}, 165\item sound if-then-else, negation and checking, 166 lazy conjunction and disjunction ({\tt *control*})\index{control!sound}, 167\item geometric reasoning about rectangles ({\tt *demo*})\index{geometric constraints}, 168\end{itemize} 169\noindent and larger constraint handlers for 170\begin{itemize} 171\item booleans for propositional logic ({\tt *bool*})\index{boolean constraints}\index{propositional logic}, 172\item finite and {\em infinite} domains (inspired by CHIP) ({\tt *domain*})\index{domain constraints}, 173\item sets ({\tt *set*})\index{set constraints}, 174\item terminological reasoning (similar to KL-ONE) \cite{fru93b} ({\tt *kl-one*})\index{terminological constraints}, 175\item temporal reasoning (over time points and intervals) \cite{fru93} ({\tt *time*})\index{temporal constraints}, 176% (quantitative and qualitative cnstr. over points and intervals) 177\item equation solving over real numbers (similar to CLP(R)) or rational numbers ({\tt *math*})\index{arithmetic constraints}\index{equation solving}. 178\end{itemize} 179\chrs\ have also been used as a committed choice programming language 180on their own ({\tt *prime*})\index{committed choice}. 181 182The example handlers can be loaded using \verb+chr(lib(File))+. For 183instance the finite domain handler can be made available as follows 184(the current directory must have write permission so that 185the {\tt pl} file can be created): 186\begin{quote} 187\begin{verbatim} 188[eclipse 1]: lib(chr), chr(lib(domain)). 189... 190domain.pl compiled traceable 241028 bytes in 1.22 seconds 191 192yes. 193[eclipse 2]: X::1..10, X ne 5. 194 195X = X 196 197Constraints: 198(4) X_g1165 :: [1, 2, 3, 4, 6, 7, 8, 9, 10] 199 200yes. 201\end{verbatim} 202\end{quote} 203 204 205 206\section{The \chr\ Language} 207 208User-defined constraints are defined by constraint handling rules 209- and optional 210\eclipse\ clauses for the built-in labeling feature. 211The constraints must be declared before they are defined. 212A \chr\ program (file extension {\tt chr}) may also include other declarations, 213options and arbitrary \eclipse\ clauses. 214%Essential are the {\tt constraints} declaration and the constraint handling rules (see next two subsections). 215\begin{center} 216\begin{tabular}{|l@{~::=~}l|} 217\hline 218Program & Statement [ Program ] \\ 219Statement & Declaration \OU Option \OU Rule \OU Clause \\ 220\hline 221\end{tabular} 222\end{center} 223Constraint handling rules involving 224the same constraint can be scattered across a file as long as they are 225in the same module and compiled together. For readability 226declarations and options should precede rules and clauses. 227 228In the following subsections, we introduce constraint handling 229rules and explain how they work. The next section 230describes declarations, clauses, options 231and built-in predicates for \chrs. 232 233 234\subsection{Constraint Handling Rules} 235 236A constraint handling rule has one or two heads, an optional guard, a 237body and an optional name. A ``Head'' is a ``Constraint''. A 238``Constraint'' is an \eclipse\ {\em callable term} (i.e. atom or 239structure) whose functor is a declared constraint. A 240``Guard''\index{guard} is an \eclipse\ goal. The {\em guard is a test} 241on the applicability of a rule. The ``Body'' of a rule is an 242\eclipse\ goal (including constraints). 243The execution of the guard and the body should not involve 244side-effects (like {\tt assert/1}, {\tt write/1}) (for more information 245see the section on writing \chr\ programs). A rule can be named with 246a ``RuleName'' which can be any \eclipse\ term (including variables 247from the rule). During debugging (see section 248\ref{chrdebug}), 249this name will be displayed instead of the 250whole rule. 251 252There are three kinds of constraint handling rules. 253\begin{center} 254\begin{tabular}{|l@{~::=~}l|} 255\hline 256Rule & SimplificationRule \OU PropagationRule \OU SimpagationRule \\ 257SimplificationRule & [ RuleName \verb/@/ ] Head [ \verb/,/ Head ] \verb/ <=>/ [Guard \verb/|/] Body. \\ 258PropagationRule & [ RuleName \verb/@/ ] Head [ \verb/,/ Head ] \verb/ ==>/ [Guard \verb/|/] Body. \\ 259SimpagationRule & [ RuleName \verb/@/ ] Head \verb/\/ Head \verb/ <=>/ [Guard \verb/|/] Body. \\ 260%Clause & Head \verb/:-/ Body. \\ 261\hline 262\end{tabular} 263\end{center} 264 265%Like clauses, \chrs\ can be read as formulas in first order logic. A 266%simplification \chr\ is a logical equivalence between the heads and 267%the body provided the guard is true. A propagation \chr\ is an 268%implication from the heads to the body provided the guard is true. 269 270Declaratively, a rule relates heads and body {\em provided the guard 271is true}. A simplification rule\index{simplification rule} means that 272the heads are true if and only if the body is true. A propagation 273rule\index{propagation rule} means that the body is true if the heads 274are true. A simpagation rule\index{simpagation rule} is a combination 275of a simplification and propagation rule. The rule ``Head1 \verb/\/ 276Head2 277\verb/<=>/ Body\verb//'' is equivalent to the simplification rule 278``Head1 \verb/,/ Head2 \verb/<=>/ Body\verb/,/ Head1\verb/./'' 279However, the simpagation rule is more compact to write, more efficient 280to execute and has better termination behavior than the corresponding 281simplification rule. 282 283\noindent {\bf Example:} 284Assume you want to write a constraint handler for minimum and maximum 285based on inequality constraints. The complete code can be found in 286the handler file {\tt minmax.chr}. \begin{verbatim} handler minmax. 287 288constraints leq/2, neq/2, minimum/3, maximum/3. 289built_in @ X leq Y <=> \+nonground(X),\+nonground(Y) | X @=< Y. 290reflexivity @ X leq X <=> true. 291antisymmetry @ X leq Y, Y leq X <=> X = Y. 292transitivity @ X leq Y, Y leq Z ==> X \== Y, Y \== Z, X \== Z | X leq Z. 293... 294built_in @ X neq Y <=> X \== Y | true. 295irreflexivity@ X neq X <=> fail. 296... 297subsumption @ X lss Y \ X neq Y <=> true. 298simplification @ X neq Y, X leq Y <=> X lss Y. 299... 300min_eq @ minimum(X, X, Y) <=> X = Y. 301min_eq @ minimum(X, Y, X) <=> X leq Y. 302min_eq @ minimum(X, Y, Y) <=> Y leq X. 303... 304propagation @ minimum(X, Y, Z) ==> Z leq X, Z leq Y. 305... 306\end{verbatim} 307%Note that the propagation rule for transitivity could loop without the guard. 308 309Procedurally, a rule can fire only if its guard succeeds. A firing 310simplification rule {\em replaces} the head constraints by the body 311constraints, a firing propagation rule keeps the head constraints and 312{\em adds} the body. A firing simpagation rule keeps the first head 313and replaces the second head by the body. See the next subsection for 314more details. 315 316 317\subsection{How \chrs\ Work} 318 319\eclipse\ will first solve the built-in constraints, 320then user-defined constraints by \chrs\, then the other goals. 321 322\noindent{\bf Example, contd.:} \begin{verbatim} 323[eclipse]: chr(minmax). 324minmax.chr compiled traceable 106874 bytes in 3.37 seconds 325minmax.pl compiled traceable 124980 bytes in 1.83 seconds 326yes. 327[eclipse]: minimum(X,Y,Z), maximum(X,Y,Z). 328X = Y = Z = _g496 329yes. 330\end{verbatim} 331 332Each user-defined constraint is associated with all rules in whose 333heads it occurs by the \chr\ compiler. Every time a user-defined 334constraint goal is added or re-activated, it checks itself the 335applicability of its associated \chrs\ by {\em trying} each \chr. To 336try a \chr, one of its heads is matched against the constraint goal. 337If a \chr\ has two heads, the constraint store is searched for a 338``partner'' constraint that matches the other head. If the matching 339succeeded, the guard is executed as a test. Otherwise the rule delays 340and the next rule is tried. 341 342The guard\index{guard} either succeeds, fails or delays. If the guard succeeds, 343the rule fires. Otherwise the rule delays and the next rule is tried. 344In the current implementation, a guard succeeds if its execution 345succeeds without delayed goals and attempts to ``touch'' a global 346variable (one that occurs in the heads). A variable is {\em touched} 347if it is unified with a term (including other variables), if it gets 348more constrained by built-in constraints (e.g. finite domains or 349equations over rationals) or if a goal delays on it (see also the {\tt 350check\_guard\_bindings} option\index{check\_guard\_bindings option}). Currently, built-in constraints used 351in a guard act as tests only (see also the section on writing good 352\chr\ programs). 353 354If the firing \chr\ is a simplification rule, the matched constraint 355goals are removed and the body of the \chr\ is executed. Similarly 356for a firing simpagation rule, except that the first head is kept. If 357the firing \chr\ is a propagation rule the 358body of the \chr\ is executed and the next rule is tried. It is remembered 359that the propagation rule fired, so it will not fire again (with the 360same partner constraint) if the constraint goal is re-activated. 361 362If the constraint goal has not been removed and all rules have been tried, 363it delays until a variable occurring in the constraint is touched. 364Then the constraint is re-activated and all its rules are tried 365again. 366 367\noindent{\bf Example, contd.:} 368The following trace is edited, 369rules that are tried in vain and redelay have been removed. 370\begin{verbatim} 371[eclipse]: chr_trace. 372yes. 373Debugger switched on - creep mode 374[eclipse]: notrace. % trace only constraints 375Debugger switched off 376yes. 377[eclipse]: minimum(X,Y,Z), maximum(X,Y,Z). 378 379ADD (1) minimum(X, Y, Z) 380TRY (1) minimum(_g218, _g220, _g222) with propagation 381RULE 'propagation' FIRED 382 383 ADD (2) leq(_g665, _g601) 384 385 ADD (3) leq(_g665, Var) 386 387ADD (4) maximum(_g601, Var, _g665) 388TRY (4) maximum(_g601, Var, _g665) with propagation 389RULE 'propagation' FIRED 390 391 ADD (5) leq(_g601, _g665) 392 TRY (5) leq(_g601, _g665) (2) leq(_g665, _g601) with antisymmetry 393 RULE 'antisymmetry' FIRED 394 395TRY (4) maximum(_g601, Var, _g601) with max_eq 396RULE 'max_eq' FIRED 397 398 ADD (6) leq(Var, _g601) 399 TRY (3) leq(_g601, Var) (6) leq(Var, _g601) with antisymmetry 400 RULE 'antisymmetry' FIRED 401 402TRY (1) minimum(_g601, _g601, _g601) with min_eq 403RULE 'min_eq' FIRED 404 405 ADD (7) leq(_g601, _g601) 406 TRY (7) leq(_g601, _g601) with reflexivity 407 RULE 'reflexivity' FIRED 408 409X = Y = Z = _g558 410yes. 411\end{verbatim} 412 413 414 415 416\section{More on the \chr\ Language} 417 418The following subsections describe declarations, clauses, options and built-in 419predicates of the \chr\ language. 420 421 422\subsection{Declarations}\index{declarations!\chr} 423 424Declarations name the constraint handler, its constraints, specify 425their syntax and use in built-in labeling. 426 427\begin{center} 428\begin{tabular}{|l@{~::=~}l|} 429\hline 430Declaration & \verb/handler/ Name\verb/./ \\ 431 & \verb/constraints/ SpecList\verb/./ \\ 432 & \verb/operator(/Precedence\verb/,/Associativity\verb/,/Name\verb/)./ \\ 433 & \verb/label_with/ Constraint \verb/if/ Guard\verb/./ \\ 434\hline 435\end{tabular} 436\end{center} 437 438The optional \verb/handler/ declaration\index{handler declaration} documents the name of the constraint 439handler. Currently it can be omitted, but will be useful in future releases for 440combining handlers. 441 442The mandatory \verb/constraints/ declaration\index{constraints declaration} lists the constraints 443defined in the handler. A ``SpecList'' is a list of Name\verb\/\Arity 444pairs for the constraints. 445The declaration of a constraint {\em must appear before} 446the constraint handling rules and \eclipse\ clauses which define it, 447otherwise a syntax error is raised. 448There can be several {\tt constraints} declarations. 449 450The optional \verb/operator/ declaration\index{operator declaration} declares an operator, with 451the same arguments as {\tt op/3} in \eclipse. However, while the usual 452operator declarations are ignored during compilation from {\tt chr} to 453{\tt pl} files, the \chr\ operator declarations are taken into account 454(see also the subsection on clauses). 455 456The optional \verb/label_with/ declaration\index{label\_with declaration} specifies when the 457\eclipse\ clauses of a constraint can be used for built-in labeling 458(see subsection on labeling). 459 460\noindent{\bf Example, contd.:} The first lines of the minmax handler are 461declarations: \begin{verbatim} 462handler minmax. 463 464constraints leq/2, neq/2, minimum/3, maximum/3. 465 466operator(700, xfx, leq). 467operator(700, xfx, neq). 468\end{verbatim} 469 470 471\subsection{\eclipse\ Clauses} 472 473A constraint handler program may also include arbitrary \eclipse\ code (written 474with the four operators \verb\:- /[1,2]\ and \verb\?- /[1,2]\). 475\begin{center} 476\begin{tabular}{|l@{~::=~}l|} 477\hline 478Clause & Head \verb/:-/ Body. \\ 479 & Head \verb/?-/ Body. \\ 480 & \verb/:-/ Body. \\ 481 & \verb/?-/ Body. \\ 482\hline 483\end{tabular} 484\end{center} 485 486Note that {\tt :-/1} and {\tt 487?-/1} {\em behave different from each other} in \chr\ programs. 488Clauses starting with {\tt :-} are {\em copied} into the {\tt pl} 489file by the \chr\ compiler, clauses with {\tt ?-} are {\em executed} 490by the compiler. As the {\tt op} declaration needs both copying and 491execution, we have introduced the special {\tt operator} declaration 492(see previous subsection on declarations). A "Head" can be a "Constraint", 493such clauses are used for built-in labeling only (see section on labeling). 494 495 496\subsection{Options}\index{options!chr} 497 498The {\tt option} command allows the user to set options in the \chr\ 499compiler. 500 501\begin{center} 502\begin{tabular}{|l@{~::=~}l|} 503\hline 504Option & \verb/option(/Option\verb/,/ On\_or\_off\verb/)./ \\ 505\hline 506\end{tabular} 507\end{center} 508 509Options can be switched on or off. {\em Default is} {\tt on}. 510Advanced users may switch an option off to improve the efficiency 511of the handler at the cost of safety. Options are: 512 513\begin{itemize} 514\item \verb/check_guard_bindings/\index{check\_guard\_bindings option}: 515When executing a guard\index{guard}, it is checked that no global variables 516(variables of the rule heads) are touched (see subsection on how 517\chrs\ work). If the option is on, guards involving cut, if-then-else 518or negation may not work correctly if a global variable has been touched before. 519If switched off, guard checking may be significantly 520faster, but only safe if the user makes sure that global variables are 521not touched. To ensure that the variables are sufficiently bound, 522tests like {\tt nonvar/1} or delays can be added to the predicates 523used in the guards. 524 525\item \verb/already_in_store/\index{already\_in\_store option}: 526Before adding a user-defined constraint to the constraint store, it is 527checked if there is an identical one already in the store. If there 528is, the new constraint needs not to be added. The handling of the 529duplicate constraint is avoided. This option can be set to \verb/off/, 530because the checking may be too expensive if duplicate constraints 531rarely occur. Specific duplicate constraints can still be removed by 532a simpagation rule of the form \verb/Constraint \ Constraint <=> true/. 533 534\item \verb/already_in_heads/\index{already\_in\_heads option}: 535In two-headed simplification rules, the intention is often to simplify 536the two head constraints into a stronger version of one of the 537constraints. However, a straightforward encoding of the rule may 538include the case where the new constraint is identical to the 539corresponding head constraint. Removing the head constraint and 540adding it again in the body is inefficient and may cause termination 541problems. If the \verb/already_in_heads/ option is on, in such a case 542the head constraint is kept and the body constraint ignored. Note 543however, that this optimization currently {\em only works if} the body 544constraint is the only goal of the body or the first goal in the 545conjunction comprising the body of the rule (see the example handler 546for domains). The option may be too expensive if identical head-body 547constraints rarely occur. 548 549\item Note that the \eclipse\ environment flag \verb/debug_compile/ (set and 550unset with \verb/dbgcomp/ and \verb/nodbgcomp/)\index{debug\_compile flag}\index{dbgcomp}\index{nodbgcomp} is also taken into 551account by the \chr\ compiler. The default is {\tt on}. 552If switched off, the resulting code is more 553efficient, but cannot be debugged anymore (see section \ref{chrdebug}). 554 555\end{itemize} 556 557 558\subsection{\chr\ Built-In Predicates} 559 560There are some built-in predicates to compile {\tt chr} files, for 561debugging, built-in labeling and to 562inspect the constraint store and remove its constraints: 563\begin{itemize} 564 565\item {\tt chr2pl(}File)\index{chr2pl/1} compiles ``File'' from a {\tt chr} to {\tt pl} file. 566 567\item {\tt chr(}File)\index{chr/1} compiles ``File'' from a {\tt chr} to 568{\tt pl} file and loads the {\tt pl} file. 569 570\item \verb/chr_trace/\index{chr\_trace/0} activates the standard debugger and 571shows constraint handling. 572%\item \verb/chr_opium/\index{chr\_opium/0} opens an Opium window for tracing including constraints. 573\item \verb/chr_notrace/\index{chr\_notrace/0} stops either debugger. 574 575\item {\tt chr\_labeling}\index{chr\_labeling/0} 576provides built-in labeling (see corresponding subsection). 577\item {\tt 578chr\_label\_with(}Constraint)\index{chr\_label\_with/1} checks if ``Constraint'' satisfies a 579{\tt label\_with} declaration (used for built-in labeling). 580\item {\tt chr\_resolve(}Constraint)\index{chr\_resolve/1} uses the \eclipse\ 581clauses to solve a constraint (used for built-in labeling). 582 583\item {\tt chr\_get\_constraint(}Constraint)\index{chr\_get\_constraint/1} 584gets a constraint unifying with ``Constraint'' from the constraint 585store and removes it, gets another constraint on backtracking. 586\item {\tt chr\_get\_constraint(}Variable,Constraint)\index{chr\_get\_constraint/2} is the same as 587{\tt chr\_get\_constraint/1} except that the constraint constrains the variable 588``Variable''. 589 590\end{itemize} 591 592 593 594 595\section{Labeling} 596 597In a constraint logic program, constraint handling is interleaved 598with making choices. Typically, without making choices, constraint 599problems cannot be solved completely. {\em Labeling}\index{labeling!CHR@\chr} 600is a controlled 601way to make choices. Usually, a labeling predicate is called 602at the end of the program which chooses values for the variables 603constrained in the program. 604% 605We will understand labeling in the most general sense as a procedure 606introducing arbitrary choices (additional constraints on constrained 607variables) in a systematic way. 608 609The \chr\ run-time system provides {\em built-in labeling}\index{labeling!CHR@\chr!built-in} for 610user-defined constraints. The idea is to write clauses for 611user-defined constraints that are used for labeling the variables in 612the constraint. These clauses are not used during constraint handling, 613but only during built-in labeling. Therefore the ``Head'' of a clause may 614be a user-defined ``Constraint''. 615% 616The {\tt label\_with} declaration\index{label\_with declaration} restricts the use of the 617clauses for built-in labeling (see subsection on declarations). There 618can be several {\tt label\_with} declarations for a constraint. 619 620\noindent{\bf Example, contd.:} \begin{verbatim} 621label_with minimum(X, Y, Z) if true. 622minimum(X, Y, Z):- X leq Y, Z = X. 623minimum(X, Y, Z):- Y lss X, Z = Y. 624\end{verbatim} 625 626The built-in labeling is invoked by calling the \chr\ built-in predicate 627{\tt chr\_labeling/0} (no arguments). Once called, whenever no more 628constraint handling is possible, the built-in labeling will choose a 629constraint goal whose {\tt label\_with} declaration is satisfied for 630labeling. It will introduce choices using the clauses of the constraint. 631 632\noindent{\bf Example, contd.:} 633A query without and with built-in labeling: \begin{verbatim} 634[eclipse]: minimum(X,Y,Z), maximum(X,Y,W), Z neq W. 635 636X = _g357 637Y = _g389 638Z = _g421 639W = _g1227 640 641Constraints: 642(1) minimum(_g357, _g389, _g421) 643(2) _g421 leq _g357 644(3) _g421 leq _g389 645(4) maximum(_g357, _g389, _g1227) 646(5) _g357 leq _g1227 647(7) _g389 leq _g1227 648(10) _g421 lss _g1227 649 650yes. 651 652[eclipse]: minimum(X,Y,Z), maximum(X,Y,W), Z neq W, chr_labeling. 653 654X = Z = _g363 655Y = W = _g395 656 657Constraints: 658(10) _g363 lss _g395 659 660 More? (;) 661 662X = W = _g363 663Y = Z = _g395 664 665Constraints: 666(17) _g395 lss _g363 667 668yes. 669\end{verbatim} 670 671Advanced users can write their own labeling procedure taking into 672account the constraints in the constraint store (see next subsection 673for \chr\ built-in predicates to inspect and manipulate the constraint 674store). 675 676\noindent{\bf Example} 677The predicate {\tt chr\_labeling/0} can be defined as: \begin{verbatim} 678 labeling :- 679 chr_get_constraint(C), 680 chr_label_with(C), 681 !, 682 chr_resolve(C), 683 labeling. 684 labeling. 685\end{verbatim} 686 687 688 689 690\section{Writing Good \chr\ Programs} 691 692This section gives some programming hints. For maximum efficiency of 693your constraint handler, see also the subsection on options, 694especially on {\tt check\_guard\_bindings}\index{check\_guard\_bindings option} and the {\tt debug\_compile}\index{debug\_compile flag}\index{dbgcomp}\index{nodbgcomp} 695flag. 696 697\subsection{Choosing \chrs} 698 699Constraint handling rules for a given constraint system can often be 700derived from its definition in formalisms such as inference rules, 701rewrite rules, sequents, formulas expressing axioms and theorems. 702% 703\chrs\ can also be found by first considering 704special cases of each constraint and then looking at interactions of 705pairs of constraints sharing a variable. Cases that don't occur in the 706application can be ignored. 707% 708\chrs\ can also improve application programs by turning 709certain predicates into constraints to provide ``short-cuts'' 710(lemmas). For example, to the predicate {\tt append/3} one can add 711{\tt append(L1,[],L2) <=> L1=L2} together with {\tt label\_with\index{label\_with declaration} 712append(L1,L2,L3) if true}. 713 714Starting from an executable specification, the rules can then be 715refined and adapted to the specifics of the application. {\em 716Efficiency can be improved} by strengthening or weakening the guards to 717perform simplification as early as needed and to do the ``just right'' 718amount of propagation. Propagation rules can be expensive, because no 719constraints are removed. If the speed of the final handler is not 720satisfactory, it can be rewritten using meta-terms or auxiliary C 721functions. 722 723The rules for a constraint can be scattered across the {\tt chr} file 724as long as they are in the same module. 725The rules are tried in {\em some order} determined by 726the \chr\ compiler. Due to optimizations this order is not necessarily 727the textual order in which the rules where written. In addition, the 728incremental addition of constraints at run-time causes constraints to 729be tried for application of rules in some dynamically determined 730order. 731 732\subsection{Optimizations} 733 734Single-headed rules should be preferred to two-headed rules which 735involve the expensive search for a partner constraint. 736Rules with {\em two heads can be avoided} by changing the ``granularity'' of 737the constraints. For example, assume one wants to express that {\em n} 738variables are different from each other. It is more efficient to have 739a single constraint {\tt all\_different(List\_of\_n\_Vars)} than 740$n^2$ 741inequality constraints (see handler {\tt domain.chr}). However, the 742extreme case of having a single constraint modelling the whole 743constraint store will usually be inefficient. 744 745{\em Rules with two heads} are more efficient, if the two heads of the 746rule share a variable (which is usually the case). Then the search for 747a partner constraint has to consider less candidates. Moreover, two 748rules with identical (or sufficiently similar) heads can be merged 749into one rule so that the search for a partner constraint is only 750performed once instead of twice. 751 752{\em Rules with more than two heads} are not allowed for efficiency 753reasons. If needed, they can usually be written as several rules with 754two heads. For example, in the handler for set constraints {\tt 755set.chr}, the propagation rule: 756\begin{verbatim} 757set_union(S1, S2, S), set(S1, S1Glb, S1Lub), set(S2, S2Glb, S2Lub) ==> 758 s_union(S1Glb, S2Glb, SGlb), 759 s_union(S1Lub, S2Lub, SLub), 760 set(S, SGlb, SLub). 761\end{verbatim} 762is translated into: 763\begin{verbatim} 764set_union(S1, S2, S), set(S1, S1Glb, S1Lub) ==> 765 '$set_union'(S2, S1, S1Glb, S1Lub, S). 766set(S2, S2Glb, S2Lub) \ '$set_union'(S2, S1, S1Glb, S1Lub, S) <=> 767 s_union(S1Glb, S2Glb, SGlb), 768 s_union(S1Lub, S2Lub, SLub), 769 set(S, SGlb, SLub). 770\end{verbatim} 771 772%The {\em efficient} translation of multi-headed simplification rules 773%requires access to the so-called ``kill-flag''. Each constraint 774%internally has a unique kill-flag. A constraint with a flag 775%\verb/Flag/ can be removed from the constraint store with the call 776%\verb/'CHRkill'(Flag)/. 777%This flag can be accessed in the head of a rule 778%using the following syntax: 779%\begin{verbatim} 780%Constraint flag Flag 781%\end{verbatim} 782 783As {\em guards}\index{guard} are tried frequently, they should be 784simple {\em tests} not involving side-effects. For efficiency and 785clarity reasons, one should also avoid using user-defined constraints 786in guards. Currently, besides conjunctions, disjunctions are allowed 787in the guard, but they should be used with care. The use of other 788control built-in predicates of \eclipse\ is discouraged. Negation and 789if-then-else can be used if their first arguments are either {\em 790simple goals} (see \eclipse\ user manual) or goals that don't touch 791global variables. Similarly, goals preceding a cut must fulfil this 792condition. 793% 794{\em Built-in constraints} (e.g. finite domains, rational arithmetic) 795work as tests only in the current implementation. 796%For example, the 797%guard \verb/X #< Y/ will not succeed before the maximum of the domain 798%of {\tt X} is less than the minimum of the domain of {\tt Y}, even if 799%constraint \verb/X #< Y/ has been imposed before. 800% 801Head matching is more efficient than 802explicitly checking equalities in the guard (which requires the {\tt 803check\_guard\_bindings}\index{check\_guard\_bindings option} flag to be on). 804% 805In the current 806implementation, local variables (those 807that do not occur in the heads) can be shared between the guard and 808the body. 809 810{\em Several handlers can be used simultaneously if} they don't share 811user-defined constraints. The current implementation will not work 812correctly if the same constraint is defined in rules of different 813handlers that have been compiled separately. In such a case, the 814handlers must be merged ``by hand''. This means that the source code 815has to be edited so that the rules for the shared constraint are 816together (in one module). Changes may be necessary (like 817strengthening guards) to avoid divergence or loops in the computation. 818 819{\em Constraint handlers} can be tightly integrated with constraints 820defined with {\em other extensions of \eclipse} (e.g. meta-terms) by using 821the \eclipse\ built-in predicate {\tt notify\_constrained(Var)} to notify 822\eclipse\ each time a variable becomes more constrained. 823This happens if a user-defined constraint is called for the first time 824or if a user-defined constraint is rewritten by a \chr\ into a stronger 825constraint with the same functor. 826 827For {\em pretty printing} of the user-defined constraints in the answer at 828the top-level and debuggers, \eclipse\ macro transformation (for write 829mode) can be used. This is especially useful when the constraints 830have some not so readable notation inside the handler. For an 831example, see the constraint handler bool {\tt bool.chr}. 832 833 834 835\section{Debugging \chr\ Programs} 836\label{chrdebug} 837 838User-defined constraints including application of \chrs\ can be traced 839with the standard debugger. 840Debugging of the \eclipse\ code is done 841in the standard way. See the corresponding user 842manual for more information. 843 844\subsection{Using the Debugger} 845 846In order to use the debugging tool, the \verb/debug_compile/ flag\index{debug\_compile flag}\index{dbgcomp}\index{nodbgcomp} 847must have been \verb/on/ (default) during compilation (\verb/chr/ to 848\verb/pl/) and loading of the produced \eclipse\ code. 849\begin{itemize} 850\item The query \verb/trace./ activates the standard debugger 851(tracing user-defined constraints like predicates). 852\item The query \verb/chr_trace./ activates the standard debugger 853showing more information about the handling of constraints. 854(application of \chrs). 855\item The query \verb/chr_notrace./ stops either debugger. 856%In case of Opium, its window remains until quited. 857\end{itemize} 858 859The debugger displays user-defined constraints and application of 860\chrs. User-defined constraints are 861treated as predicates and the information about application of \chrs\ 862is displayed without stopping. See the 863subsection on how \chrs\ work for an example trace. The additional 864ports are: 865\begin{itemize} 866 \item \verb/add/: A new constraint is added to the constraint store. 867 868 \item \verb/already_in/: A constraint to be added was already present. 869\end{itemize} 870 871The ports related to application of rules are: 872\begin{itemize} 873 \item \verb/try_rule/: A rule is tried. 874 875 \item \verb/delay_rule/: The last tried rule cannot fire because the guard did not succeed. 876 877 \item \verb/fire_rule/: The last tried rule fires. 878\end{itemize} 879 880The ports related to labeling are: 881\begin{itemize} 882 \item \verb/try_label/: A label\_with declaration is checked. 883 884 \item \verb/delay_label/: The last label\_with declaration delays because the guard did not succeed. 885 886 \item \verb/fire_label/: The last tried label\_with declaration succeeds, 887so the clauses of the associated constraint will be used for built-in labeling. 888 889\end{itemize} 890When displayed, each constraint 891is labelled with a unique integer identifier. Each rule is labelled 892with its name as given in the {\tt chr} source using the \verb/@/ 893operator. If a rule does not have a name, it is displayed together 894with a unique integer identifier. 895 896\section{The Extended \chr\ Implementation} 897\label{newchr} 898 899A new, extended, {\tt chr} library has been developed, with the intention of providing 900the basis for a system that will allow more optimisations than the previous 901implementation. At the same time, some of the syntax of the \chr\ has 902been changed to conform better to standard Prolog. 903 904The system is still experimental, and provides no special support for 905debugging {\chr\ } code. Please report any problems encountered while 906using this system. 907 908The main user visible differences from the original {\tt chr} library are as 909follows: 910 911\begin{itemize} 912\item The extended library produces code that generally runs about twice as fast 913as the old non-debugging code. It is expected that further improvements 914should be possible. 915\item \chr\ code is no longer compiled with a special command -- the normal 916compile command will now recognise and compile \chr\ code when the extended 917{\tt chr} library is loaded. No intermediate Prolog file is produced. The 918{\tt .chr} extension is no longer supported implicitly. 919\item Syntax of some operators have been changed to conform better to standard 920Prolog. 921\item A framework for supporting more than two head constraints has been 922introduced. However, support for propagation rules with more than two heads 923have not yet been added. Simplification and simpagation rules with more 924than two heads are currently supported. 925\item The compiler does not try to reorder the {\chr\ } any more. Instead, 926they are ordered in the way they are written by the user. 927\item {\tt label_with} is no longer supported. It can be replaced with 928user defined labelling. 929\item The operational semantics of rules have been clarified. 930\item The {\chr\ } are run at the same priority before and after 931suspensions. Priorities can be specified for {\chr\ } constraints. 932\item There is no special support for debugging yet. The \chr\ code would be 933seen by the debugger as the transformed Prolog code that is generated by 934the compiler. 935\end{itemize} 936 937\subsection{Invoking the extended CHR library} 938 939The extended library is invoked by \verb'lib(ech)'. Given that it is now 940integrated into the compiler. It can be invoked from a file that contains 941{\chr\ } code, as \verb':- lib(ech).', as long as this occurs before the CHR 942code. 943 944\subsection{Syntactic Differences} 945 946As programs containing {\chrs} are no longer compiled by a separate process, 947the {\tt .chr} extension is no longer implicitly supported. Files with 948the {\tt .chr} extension can still be compiled by explicitly specifying 949the extension in the compile command, as in {\tt ['file.chr']}. Associated 950with this change, there are some changes to the declarations of the {\tt .chr} 951format: 952 953\begin{itemize} 954\item {\tt operator/3} does not exist. It is not needed because the 955standard Prolog {\tt op/3} declaration can now handle all operator 956declarations. Replace all {\tt operator/3} with {\tt op/3} declarations. 957\item The other declarations {\tt handler constraints option} are now handled 958as normal Prolog declarations, i.e. they must be preceded with 959{\tt :-}. This is to conform with standard Prolog syntax. 960\end{itemize} 961 962The syntax for naming a rule has been changed, because the old method (using 963{\tt @} clashes with the use of {\tt @} in modules. The new operator 964for naming rules is {\tt ::=}. Here is part of the minmax handler in the 965new syntax: 966 967\begin{verbatim} 968:- handler minmax. 969:- constraints leq/2, neq/2, minimum/3, maximum/3. 970:- op(700, xfx, leq). 971 972built_in ::= X leq Y <=> \+nonground(X), \+nonground(Y) | X @=< Y. 973reflexivity ::= X leq X <=> true. 974... 975\end{verbatim} 976 977\subsection{Compiling} 978 979After loading the extended {\tt chr} library, programs containing \chr\ code can 980be compiled directly. Thus, \chr\ code can be freely mixed with normal Prolog 981code in any file. In particular, a compilation may now compile code from 982different files in different modules which may all contain \chr\ codes. This 983was a problem with the old library because \chr\ code had to be compile 984separately. 985 986In the extended library, \chr\ code can occur anywhere in a particular module, and 987for each module, all the \chr\ code (which may reside in different files) 988will all be compiled into one unit ({\tt handler} declarations are ignored 989by the system, they are present for compatibility purposes only), with the 990same constraint store. \chr\ code in different modules are entirely 991separate and independent from each other. 992 993In order to allow \chr\ code to occur anywhere inside a module, and also 994because it is difficult to define a meaning for replacing multi-heads rules, 995compilation of \chr\ code is always incremental when a new file for a 996module is compiled, i.e. any existing \chr\ 997code in a module is not replaced by those in the newly compiled 998file. However, when the whole module is recompiled (i.e. compiling a file 999with the \verb'module/1' directive), or if the module is erased, then any 1000existing CHR code in the module is erased along with the other code in the 1001module. 1002 1003It is possible to clear out old \chr\ code in all modules when compiling a 1004file. This is done 1005with the {\tt chr/1} predicate. This first remove any existing \chr\ code in 1006any module before the compilation starts. It thus approximates the semantics 1007of {\tt chr/1} of the old library, but no Prolog file is generated. It is 1008mainly intended for compatibility with the old library, and when you are 1009using CHR without using the module facilities. 1010 1011\subsection{Semantics} 1012 1013\subsubsection{Addition and removal of constraints} 1014 1015In the old {\tt chr} library, it was not clearly defined when a constraint 1016will be added to or removed from the constraint store during the execution of 1017a rule. 1018In the extended {\tt chr} library, all head constraints 1019that occur in the head of a rule are mutually exclusive, i.e. they cannot 1020refer to the same constraint. This ensures that similar heads in a rule 1021will match different constraints in the constraint store. 1022Beyond this, the state of a constraint -- if it 1023is in the constraint store or not -- that has been matched in the head 1024is not defined during the execution of the rest of the head and guard. 1025As soon as the guard is satisfied, any constraints removed by a rule will 1026no longer be in the constraint store, and any constraint that is not 1027removed by the rule will be present in the constraint store. 1028 1029This can have an effect on execution. For example, in the finite domain 1030example in the old {\tt chr} directory ({\tt domain.chr}), there is the following rule: 1031 1032\begin{verbatim} 1033 X lt Y, X::[A|L] <=> 1034 \+nonground(Y), remove_higher(Y,[A|L],L1), remove(Y,L1,L2) | 1035 X::L2. 1036\end{verbatim} 1037 1038Unfortunately this rule is not sufficiently specified in the extended 1039\chr, and can lead to looping under certain circumstances. The two {\tt 1040remove} predicate in the guard removes elements from the domain, but if no 1041elements are removed (because \verb+X lt Y+ is redundant, e.g. \verb+X lt 5+ with 1042\verb+X::[1..2]+), then in the old \chr\ execution, the body goal, the constraint 1043\verb+X::L2+ would not be actually executed, because the older constraint in 1044the head (the one that matched \verb+X::[A|L]+) has not yet been removed when 1045the new constraint is imposed. With the extended \chr, the old constraint 1046is removed after the guard, so the \verb+X::L2+ is executed, and this can 1047lead to looping. The rule should thus be written as: 1048 1049\begin{verbatim} 1050 X lt Y, X::[A|L] <=> 1051 \+nonground(Y), remove_higher(Y,[A|L],L1), remove(Y,L1,L2), 1052 L2\==[A|L] | 1053 X::L2. 1054\end{verbatim} 1055 1056\subsubsection{Executing Propagation and simpagation rules} 1057 1058Consider the following propagation rule: 1059 1060\begin{verbatim} 1061 1062p(X), q(Y) ==> <Body>. 1063 1064:- p(X). 1065\end{verbatim} 1066 1067The execution of this rule, started by calling \verb'p(X)', will try to match 1068all \verb'q(Y)' in the constraint store, and thus it can be satisfied, 1069with \verb'<Body>' executed, 1070multiple number of times with different \verb'q(Y)'. \verb'<Body>' for 1071a particular \verb'q(Y)' will be executed first, before trying to match 1072the next \verb'q(Y)'. The execution of \verb'<Body>' may however cause the 1073removal of \verb'p(X)'. In this case, no further matching with \verb'q(Y)' 1074will be performed. 1075 1076Note that there is no commitment with propagation and simpagation rule 1077if the constraint being matched is not removed: 1078 1079\begin{verbatim} 1080p(X), q(Y) ==> <Body1>. 1081p(X), r(Y) ==> <Body2>. 1082 1083:- p(X). 1084\end{verbatim} 1085 1086Both rules will always be executed. 1087 1088The body of a rule is executed as soon as its guard succeeds. In the case 1089of propagation rules, this means that the other propagation rules for this 1090constraint will not be tried until the body goals have all been executed. 1091This is 1092unlike the old \chr, where for propagation rules, the body is not executed 1093until all the propagation rules have been tried, and if more than one 1094propagation rule has fired (successful in its guard execution), then the 1095most recently fired rule's body is executed first. For properly written, 1096mutually exclusive propagation rule, this should not make a difference 1097(modulo the effect of the removal of constraints in the body). 1098 1099\subsubsection{Execution Priority} 1100 1101The priority at which an ECH rule is executed depends on the `active' 1102constraint, i.e.\ the constraint that triggered the execution of the 1103rules. Normally, the ECH rules are executed at the {\it default\/} 1104priority, but a different priority can be associated with a constraint when it 1105is declared, specifying the priority at which the ECH rules will be executed 1106when that constraint is the active constraint. 1107 1108\begin{verbatim} 1109:- constraints chr_labeling/0:at_lower(1). 1110\end{verbatim} 1111 1112\noindent 1113this specifies that if {\tt chr_labeling/0} was the active constraint, then 1114the rules will be executed at a lower priority than the default. The 1115priorities are mapped to the priority system of {\eclipse}, and {\tt 1116at_lower(1)} maps to a priority one lower than the default, so that ECH 1117rules executing at the default priority will execute first. This is 1118particularly useful for labelling, as this allow the other ECH constraints 1119to be executed during the labelling process rather than afterwards. 1120 1121The priority specified can be {\tt at_lower(N)}, {\tt at_higher(N)}, or 1122{\tt at_absolute_priority(N)}. For {\tt at_lower(N)}, the priority is the 1123default + N; for {\tt at_higher(N)}, it is the default - N. {\tt 1124at_absolute_priority(N)} sets the priority to N, regardless of the default, 1125and its use is not recommended. The available priorities are from 1 1126(highest) to 11 (lowest). The default priority is initially set to 9, but 1127can be changed with the {\tt chr_priority} option. Note that the priority 1128at which the rules will run at is determined at compile time, and changing 1129the default priority will only affect new constraints compiled after the 1130change. It should therefore only be used in a directive before any of the 1131ECH rules. 1132 1133This behaviour is different from the old {\tt chr} library, and from older 1134versions of {\tt ech} library, where the rules ran at different 1135priorities before and after suspension. This can lead to different 1136behaviours with the same rule, either with other constraints solvers, or 1137even with other CHR rules, as a woken CHR executes at much higher priority 1138than the initial run. With the current {\tt ech} execution, the rules are 1139executed at the same priority before and after suspension, for the same 1140active constraint. The default priority is set at 9 so that it is very 1141likely to be lower than the priority used in other constraint solvers. The 1142user is now allowed to alter the priority of specific ECH constraints to 1143allow the user more control so that for example a labelling rule can run at 1144a lower priority than the other constraints. 1145 1146\subsection{Options and Built-In Predicates} 1147 1148The \verb'check_guard_bindings' and \verb'already_in_store' options from 1149the old {\tt chr} library are supported. Note that the extended compiler can 1150actually detect some cases where guard bindings cannot constrain any global 1151variables (for example, \verb'var/1'), and will in such cases no check 1152guard bindings. 1153 1154New options, intended to control the way the compiler tries to optimise 1155code, are introduced. These are intended for the developers of the compiler, 1156and will not be discussed in detail here. The only currently supported 1157option in this category is \verb'single_symmetric_simpagation'. 1158 1159Another new option, \verb'default_chr_priority', allows the default 1160priority to be changed, e.g. 1161 1162\begin{verbatim} 1163:- option(default_chr_priority, 6). 1164\end{verbatim} 1165 1166\noindent 1167changes the default priority to 6, so the compiler would generate new CHR 1168code which defaults to this priority (unless overridden in the constraints 1169declaration). The available values are from 1 to 11. 1170 1171The old {\chr\ } built-ins, \verb'chr_get_constraint/1' and 1172\verb'chr_get_constraint/2' are both implemented in this library. 1173 1174A new built-in predicate, \verb'in_chrstore/1', is used to inspect the 1175constraint store: 1176 1177\begin{verbatim} 1178in_chrstore(+Constraint) 1179\end{verbatim} 1180 1181\noindent 1182is used to test if \verb'Constraint' is in the constraint store or not. It 1183can be used to prevent the addition of redundant constraints: 1184 1185\begin{verbatim} 1186X leq Y, Y leq Z ==> \+in_chrstore(X leq Z)| X leq Z. 1187\end{verbatim} 1188 1189The above usage is only useful if the \verb'already_in_store' option is 1190off. Note that as the state of a constraint that appears in the head is 1191not defined in the guard, it is strongly suggested that the user does not 1192perform this test in the guard for such constraints, 1193 1194\subsection{Compiler generated predicates} 1195 1196A source to source transformation is performed on \chr\ code by the compiler, 1197and the resulting code is compiled in the same module as the \chr\ code. These 1198transformed predicates all begin with 'CHR', so the user should avoid using 1199such predicates. 1200 1201 1202\index{library!chr.pl|)} 1203 1204%HEVEA\cutend 1205 1206 1207 1208