Re: Q about CHRs

Dear Ulrich,


>I guess "re-activated" includes the application of notify_constrained/1 to
>one of the variables in the head of the CHR.  Is it possible to identify
>this variable (these variables) in the guard of a constraint handling rule?

CHRs are implemented using the suspension mechanism of ECLiPSe. When a
suspended goal is woken and executed, it is in general difficult to
`identify' which variable caused it to wake up [the idea is that you would
create different suspended goals if you want this, for example,

suspend(constrained_x(X,Y), 4, X->constrained),
suspend(constrained_y(X,Y), 4, Y->constrained),

instead of

suspend(constrained_xy(X,Y), 4, (X,Y)->constrained),

This is not done for the CHR suspensions, so there is no easy way of
`identifying' the variable(s) that cause a CHR to re-activate.

>Is it possible to add a rule to the CHR compiler without initiating the
>checking process as a result of this insertion (checking it later is OK, of
>course)?

No, I don't think so.

>The rationale behind my questions is that some guards are compuationally
>expensive and I want to avoid unnecessary tests.  

You may be better off using suspensions directly if you want this sort of
flexibility. However, you may be able to put in a cheap guard test before
the computationally expensive one, which would fail and thus the expensive
one would not be done. 

There is obviously a case for better compilation/analysis of the CHR rules,
but the resources at IC-Parc is limited, and since the CHRs rules don't
seem to be used that much, we haven't devoted that much resources to it.

Cheers,

Kish