kiniry / Mobius

4 stars 8 forks source link

esc/java2 problems with axioms #85

Open atiti opened 11 years ago

atiti commented 11 years ago

From: David Cok cok@frontiernet.net Date: 4 March, 2006 20:20:33 GMT To: Michal Moskal michal.moskal@gmail.com, Joe Kiniry <kiniry@acm.org

Subject: Re: esc/java2 problems with axioms Reply-To: cok@frontiernet.net

Joe,

Since you and your students are writing other logics, I thought I would involve you in this discussion.

I agree with Michal that an inconsistency is present here. The right way to resolve it depends on the interpretation of types and of 'is' :-)

The original axioms for numeric types have T_byte, T_int etc. being final types, that is no subtypes. However, numberic values can be more than one type (using is) - is(0,T_byte) and is(0,T_int) are both true.

The typeof function was also originally defined for objects as the dynamic type of a (reference) value. So 'is' works nicely with 'typeof' for reference objects (with the minor complication of null values): (BG_PUSH (FORALL (x t) (PATS (MPAT (<: t |T_java.lang.Object|) (is x t))) (IMPLIES (<: t |T_java.lang.Object|) (IFF (is x t) (OR (EQ x null) (<: (typeof x) t))))))

Note also that is(x,t) is true for many t if x is null, just as when x is a primitive numeric value.

Note that JML allows \typeof to be applied to primitive variables, expressions and literals. It is translated by jmlc as the type of the expression. A literal such as '0' is int. This works because Java distinguishes int literals from long literals etc. Thus in JML, for example, \typeof(0) != \type(byte). \typeof on a primitive expression is translated directly to a literal type value (no use of Simplify's typeof). The logic underlying Simplify just has numeric values. Thus \typeof in JML is somewhat different than typeof in Simplify.

Given all of this, I believe that I was in error to introduce the axioms

(BG_PUSH (FORALL (x) (PATS (typeof x)) (IFF (is x |T_byte|) (EQ (typeof x) |T_byte|)) )) (BG_PUSH (FORALL (x) (PATS (typeof x)) (IFF (is x |T_int|) (EQ (typeof x) |T_int|)) )) etc.

'is' on numbers has a kind of subset relationship but not a subtype relationship (since the primitive types are final). At most we can say (IF (EQ (typeof x) |T_byte|) (is x |T_byte|)) But since Simplify's numbers are simply mathematical integers or reals, so defining typeof on Simplify's values is problematic; thus it is probably better not to introduce this axiom schema either.

Unfortunately, I do not have a record of the kind of code for which these axioms were needed to complete a verification.

Thoughts?

Michal Moskal wrote:

Hi,

I'm developing a theorem prover and using formulas generated by ESC/Java2 as test cases. I found you have added the following axioms to the set of universal axioms:

(BG_PUSH (FORALL (x) (PATS (typeof x)) (IFF (is x |T_byte|) (EQ (typeof x) |T_byte|)) )) (BG_PUSH (FORALL (x) (PATS (typeof x)) (IFF (is x |T_int|) (EQ (typeof x) |T_int|)) ))

The other axioms, previously present there are:

(BG_PUSH (FORALL (x) (PATS (is x |T_byte|)) (IFF (is x |T_byte|) (AND (<= -128 x) (<= x 127))))) (BG_PUSH (FORALL (x) (PATS (is x |T_int|)) (IFF (is x |T_int|) (AND (<= intFirst x) (<= x intLast)))))

The imply that (is 100 |T_int|) and (is 100 |T_byte|), which, with your axiom implies that (EQ (typeof 100) |T_int|) and (EQ (typeof 100) |T_byte|), which in turn implies (through equality transitivity) that (EQ |T_int| |T_byte|), which is of course wrong.

I'm not sure if I got something wrong here, but it seems this prevents my prover from proving toArray() assertions in a few classes. I'm not sure how Simplify handles that, but it doesn't seem right for the axiom set to be inconsitant.

I'm writing just to let you know, I'm not actually using ESC/Java2, just using it as a testcase.

atiti commented 11 years ago

From: dcochran (GH: dcochran) Date: Mon Jun 30 11:36:23 2008

Milestone ESCJava2.0b5 release deleted