Re: [eclipse-clp-users] Questions about ECR

From: Kish Shen <kisshen_at_...5...>
Date: Wed, 28 Jan 2009 13:14:48 +0000
Hi Ulrich,

Ulrich Scholz wrote:
> Hello Kish and all,
> 
> I have some questions and comments regarding the ECH library.
> 
> - The chr/1 predicate allows to clear out old CHR code before compiling new
>   ones.  In ECH, this predicate looks really awkward because the argument
>   has to be a file and is not really used.  In particular, the file is not
>   compiled as in CHR.  I'd be happy if a new version of the library could
>   provide a more intuitive predicate.
>

The chr/1 predicate is mainly there for compatibility with the old 
lib(chr), and for compiling ech CHR code that are not module based (i.e. 
like the old lib(chr)). The intended use case is that you use it to 
compile a file with ech CHR code instead of using the normal compile 
predicates (e.g. [<file>]). It has the side effect of erasing CHR code 
in *all* modules, which is not normally a good idea if you have CHR code 
in different modules.

If you are using CHR code within a module, and you recompile the module 
(i.e. compile a file with the module/1 directive for the module), then 
the old module is erased, and the CHR code in that module is also 
properly cleared out. So in this case you do not need to use chr/1 to 
clear out the old CHR code first. The CHR manual is not too clear on 
this, and I will clarify the description there.

Given that old CHR code is cleared out first when a module is 
recompiled, it doesn't make much sense to provide a predicate to clear 
out all existing CHR codes.

> - Another question about chr/1 and ECH: Some time ago, this list gave me the
>   following advice on how to remove old ECLiPSe code.  At those times, I did
>   not use CHR or ECH.
> 
>     % [...] turn your file into a module, i.e., add a :- module(mymodule).
>     % directive to it.  Then the module will be automatically erased before
>     % every recompilation.  If you don't want to bother learning about
>     % modules, you can choose 'eclipse' as the module name, then you should
>     % see no further difference in behaviour.
> 
>   That trick doesn't seem to work in combination with chr/1 in ECH: There is
>   an error on compiling the second time, see below.  So, what is the best
>   way to erase the old clauses and to erase the CHR store?
> 

You don't need to use chr/1 when you are using the module directive.
You mention 'CHR store' here, instead of 'CHR code'. If by 'CHR store' 
you mean the CHR constraint store, then this is not an issue, because 
this store only exist during execution, and is not persistent (like 
other constraints).

> test.ecl:
> --
> :- module(eclipse).
> 
> :- lib(ech).
> 
> % to clean out the constraint store
> %
> :- chr(empty).
> 
> :- handler typemodule.
> 
> % CHR constraints
> :- constraints typeSameset/2.
> --
> 
> empty.ecl
> 
> This is an empty file, i.e., a file with zero bytes length.
> 
> 
> 
> [scholzuh_at_...161...:ECH] >eclipse
> ECLiPSe Constraint Logic Programming System [kernel]
> Kernel and basic libraries copyright Cisco Systems, Inc.
> and subject to the Cisco-style Mozilla Public Licence 1.1
> (see legal/cmpl.txt or www.eclipse-clp.org/licence)
> Source available at www.sourceforge.org/projects/eclipse-clp
> GMP library copyright Free Software Foundation, see legal/lgpl.txt
> For other libraries see their individual copyright notices
> Version 6.0 #42 (i386_linux), Wed Sep 24 01:37 2008
> [eclipse 1]: [test].
...
> Yes (0.38s cpu)
> [eclipse 2]: -1.
> [test].
> record does not exist in abolish_record_body('CHRcode', eclipse)
> ERROR: test.ecl:3:
>   Query exited (abort): :- chr(empty)
> Error(s) occurred while compiling /home/scholzuh/Forschung/Invarianten/ECH/test.ecl
> Aborting execution ...
> Abort
> [eclipse 3]:
> 

The bug is provoked by your unexpected way of using chr/1 -- the 
existing lib(ech) does not initialise the module correctly for CHR code 
in the way you are using it -- a fix for this will be checked in.

You are using chr/1 in two unexpected ways here:

1. As a directive within a file you are compiling. The expected use case 
is that you use chr(test) instead of [test] as your queries. If you do 
this, then test should be compiled correctly without errors.

Using chr/1 as a directive within a compiled file is almost certainly a 
bad idea, because it has the effect of erasing existing CHR code in 
*all* modules, and not just the module you are compiling.

2. the file you are compiling with chr/1 -- empty.ecl does not contain 
any chr code.

Since test.ecl has a module/1 directive, you don't need to use chr/1 in 
any case.

So my suggestion to avoid the problem you get is to simply remove the :- 
chr(empty) directive from test.pl.

Cheers,

Kish

-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.
Received on Wed Jan 28 2009 - 13:15:13 CET

This archive was generated by hypermail 2.3.0 : Wed Sep 25 2024 - 15:13:20 CEST