next up previous contents
Next: The Object/ANY class Up: Predicates in rules Previous: Linear path expressions

Type inference for simple predicates

looks up the field name in the data model and annotates with the predicate a set of types (in CoSy-fSDL operator/domain pairs). This is a set of types because a field can turn up in several objects. In CoSy-fSDL also operators may be contained in several domains. These sets of alternative types are then intersected and unified against each other during the type inference. always tries to retain finer types, i.e. more specific types, which then provides better information for code generation. The rules according two types are compared are the following:

At the end of the type inference process there should be unique types for all variables in rules. If not, will prompt an error. Either this is a real typing error or the user can give more type information to by providing inheritance declarations (section 2.3.3) or variable declarations (section 3.4).

In CoSy-fSDL-mode however, this scheme currently has one restriction. If a field is contained in several operators, and is not a shared field, then the user has to specify with the field a domain/operator specification. E.g. in the CCMIR the field Then occurs in operator mirIf as well as in mirTryAcquire. A predicate using it in domain mirIf should look like:

  
Then@mirSimpleSTMT@mirIf(Stmt, ThenPart)

If the field is a shared field between all operators that use it, the field alone is sufficient as predicate name.


 
next up previous contents
Next: The Object/ANY class Up: Predicates in rules Previous: Linear path expressions
Uwe Assmann
1998-12-22