Bug in ech?

From: J.R. van Ossenbruggen <Jacco.van.Ossenbruggen_at_cwi.nl>
Date: Mon 23 Jul 2001 03:41:03 PM GMT
Message-Id: <200107231541.f6NFf3x20538@spinaker.ins.cwi.nl>
We came across some strange behavior of ech.  Is this a bug or
are we missing something?  Thanks for your help,

	Jacco

This is our narrowed down chr file, "tr":

  handler tr.

  :-lib(fd).

  constraints tr/3.

  % cleaning rules
  tr('b','b','b') <=> true.

  % propagation rules
  tr('b','b',X) ==> X #= b.

Sample session using ech:
ECLiPSe Constraint Logic Programming System [kernel]
Copyright Imperial College London and ICL
Certain libraries copyright Parc Technologies Ltd
GMP library copyright Free Software Foundation
Version 5.2 #10, Tue Jun 26 02:14 2001
[eclipse 1]: lib(ech),compile('tr.chr').
lists.pl   compiled traceable 5188 bytes in 0.02 seconds
strings.pl compiled traceable 0 bytes in 0.01 seconds
numbervars.pl compiled traceable 764 bytes in 0.01 seconds
ech2pl.pl  compiled traceable 77044 bytes in 0.03 seconds
ech.pl     compiled traceable 32688 bytes in 0.10 seconds
WARNING: Hiding imported predicate handler/1 from module ech in module eclipse (use local/1)
fd_domain.eco loaded traceable 0 bytes in 0.02 seconds
fd_arith.eco loaded traceable 0 bytes in 0.07 seconds
fd_util.pl compiled traceable 2128 bytes in 0.01 seconds
fd_chip.pl compiled traceable 4720 bytes in 0.03 seconds
fd_elipsys.pl compiled traceable 11036 bytes in 0.02 seconds
fd.eco     loaded traceable 0 bytes in 0.13 seconds
Found CHR tr/3, generating transformed code
tr.chr     compiled traceable 28 bytes in 0.13 seconds

Yes (0.25s cpu)
[eclipse 2]: X::['e','b'],tr(b,b,X).

No (0.00s cpu)
[eclipse 3]: 

Here I expected 'Yes', with X=b.

Strange enough, when I run this through Eclipse 5.11 with the
old chr library, it works OK:

ECLiPSe Constraint Logic Programming System [kernel]
Copyright Imperial College London and ICL
Certain libraries copyright Parc Technologies Ltd
GMP library copyright Free Software Foundation
Version 5.1.1, Thu Feb 22 01:08 2001
[eclipse 1]: lib(chr),chr2pl('tr'),[tr].    
strings.pl compiled traceable 0 bytes in 0.01 seconds
chr2pl.eco compiled traceable 0 bytes in 0.03 seconds
chr.eco    compiled traceable 0 bytes in 0.04 seconds
lists.pl   compiled traceable 5188 bytes in 0.01 seconds
tr.chr     compiled traceable 1686 bytes in 0.02 seconds
fd_domain.eco compiled traceable 0 bytes in 0.01 seconds
fd_arith.eco compiled traceable 0 bytes in 0.05 seconds
fd_util.pl compiled traceable 2052 bytes in 0.01 seconds
fd_chip.pl compiled traceable 4644 bytes in 0.02 seconds
fd_elipsys.pl compiled traceable 10564 bytes in 0.01 seconds
fd.eco     compiled traceable 0 bytes in 0.10 seconds
tr.pl      compiled traceable 2284 bytes in 0.10 seconds

yes.
[eclipse 2]: X::['e','b'],tr(b,b,X).

X = b
yes.

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)


Any help would be appreciated,

Jacco
Received on Mon Jul 23 16:41:14 2001

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