Re: Q about CHRs

From: Kish Shen <ks15_at_icparc.ic.ac.uk>
Date: Tue 26 Jul 2005 01:09:05 PM GMT
Message-ID: <rqr7dl1zpq.fsf@cow.icparc.ic.ac.uk>
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 
Received on Tue Jul 26 14:13:03 2005

This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:07:38 PM GMT GMT