Re: OCL 2.0 Type Inference

Date view Thread view Subject view Author view Attachment view
Date: Mon 22 Dec 2003 - 18:40:15 GMT


I will reply to Alexandre and Adrian both:

Quoting Alexandre Correa <>:
> Hi,
> the operation commonSuperType defined on page 3-22 states that the type can 
> be "ANY" of the most common supertype of the classifiers. In the example 
> given by Brian, the result would be Set{A , B}->any(true), e.g., both A and 
> B could be the most common supertype of the classifiers C and D. Comments??

Thank you for pointing out the commonSuperType operation to me. It seems like
the definition of this operation is not correct if it is to be used for type
inference because it makes the inference indeterminate because commonSuperType
is not functional.

Adrian wrote:

> >1. Since both A,B are supertypes of C,D, we can't choose either of them
> >    as common supertype, so the answer should be OclAny, making the type of
> >    Sequence{c,d} Sequence(OclAny).

This is using the intuitive semantics of commonSuperType but the actual
semantics for it in the specification do not match this (as Alexandre mentioned

> >2. 3. 4. If Sequence{c,d} has the type Sequence(OclAny) then the iterator
> >          v has the type OclAny. Since OclAny.a and OclAny.b do not exist
> >          any compiler should stop here with a feature not found message.
> >          Since we have a compilation error I don't think we should talk
> >          about the expression being undefined. It is simply semantically
> >          incorect.

I guess my choice of the word "undefined" was poor since OCL has its own
definition of this. In particular, a well-typed expression can be well-defined
to evaluate to OCL's "undefined" value. 


Date view Thread view Subject view Author view Attachment view