Re: Bug in ech?

Dear Jacco,

Thank you for reporting the problem with the ech library.

>We came across some strange behavior of ech.  Is this a bug or
>are we missing something?  Thanks for your help,

Yes, it is a bug. It was due to an over-eager optimisation which removed a
test it should not have. This only happens if the last rule for a
particular head is a propagation rule which triggers the removal of the
same head from the constraint store in the body: there should be a test to
see if the head has been removed. This will be fixed in the next patch
release of ECLiPSe.

>What is going on here?  When I remove the clean up rule,
>ech gives me X=b, but with a delayed rule tr(b,b,b), which is
>not what I want:
>
>[eclipse 3]: X::['e','b'],tr(b,b,X).
>
>X = b
>
>Delayed goals:
>        tr(b, b, b)
>Yes (0.00s cpu)

I am not sure if I am missing something, but this seems to be the expected
behaviour. With only the propagation rule, tr/3 will be left behind in the
constraint store. This is also the behaviour with chr library.

Some points about your code:

>  handler tr.

>  constraints tr/3.

These should be directives in ech library. It seems that in your actual
code, you did make constraints/1 a directive, but not handler/1, which is
why you got the warning:

>WARNING: Hiding imported predicate handler/1 from module ech in module
>eclipse (use local/1)

You don't need the handler/1 declarations in ech (in fact they are
ignored), so the above did not cause any problem. 

Yours sincerely,

Kish Shen
IC-Parc