Thanks, for the pointer. This is certainly at least a starting point. But I think I'll require
public Var mod(Var var)...
Let me elaborate on my use case (I'm curious about your thoughts about this anyway ;)):
In my use case (object-oriented configuration) a user should be able to select the type of a part (which corresponds to a Java type since part-components are represented as classes) within the configuration. Translated to CSP, this means there is a variable x holding the Java type of the part. Sometimes it's required to impose some constraint to that type, say a constraint should be established that says that the type assigned to x should be a sub-type of class A. If B extends A, then x = B should be valid as well as x = A. However, a type C (not extending A) should be ruled out by the constraint.
Now, of course CSP's don't have support for the variable type "Java Class" neither does any constraint for that type natively exist. My idea was to represent the type hierarchy using prime numbers as follows:
every Java type gets assigned two numbers:
a) a unique prime number: say type(A) = 2, type(B) = 3, type(C) = 5, type(D) = 7...
b) an (also by definition unique) number that represents the type closure of a type: closure(A) = type(2) = 2, closure(B extends A) = type(B) * closure(A) = 3*2 = 6, closure(C) = type(C) = 5, closure(D extends B) = type(D) * closure(B) = 7*3*2 = 42, ...
So, I'd assign the number that represents the closure to x and state a constraint "the type represented by x must be a subtype of A" as "x mod 2 = 0" (or "x mod closure(...) = 0" in general). Back to the question whether 2 should be a variable value here: I think yes, it's very likely that there will exist another constraint that will dynamically constrain the required type...
Would be great if you could add the method in one of the next releases of the spec.
Thanks very much!
Cheers,
Vivian