TEL (Version 0.9) Report and User Manual

type declaration ! type dec lhs `:=' `abstract' `.' type dec lhs ! identi er [ `(' f variable g `)' ] j pre x operator variable j variable in x operator variable j variable post x operator the occurring variables must be pairwise distinct type abbreviation ! type dec lhs `:=' nonvariable type term every variable that occurs in the left-hand side must occur in the right-hand side and vice versa type de nition ! type dec lhs `:=' type def rhs `.' every variable that occurs in the left-hand side must occur in the right-hand side and vice versa type def rhs ! (subtype speci cation `++' ) subtype speci cation `++' subtype speci cation j (subtype speci cation `++' ) `{' f constructor de nition g `}' subtype speci cation ! nonvariable type term constructor de nition ! designator [ `:' domain ] domain ! type term [ `x' domain ] designator ! identi er j operator A nonabstract type declaration is called a de nition since it completely de nes the declared type constructor. Note that the right-hand side of a type de nition contains further declarations, namely, constructor declarations. Analogous to type declarations, constructor declarations are called de nitions since they de ne the declared constructor completely. parameter declaration ! `par' identi er `:' ground type term `.' function declaration ! designator `:' f rank g `.' all ranks must specify the same number of arguments rank ! domain `-->' type term j domain `>->' type term every variable occurring in the codomain of a rank must occur in the domain of the rank relation declaration ! rel class designator `:' io domain `.' rel class ! `tdrel' j `drel' j `trel' j `rel' io domain ! [ `?' ] type term [ `x' io domain ] every variable occurring in the type term of an output argument must occur in the type term of an input argument procedure declaration ! proc class designator `:' [ io domain ] `.' proc class ! `tproc' j `proc' A signature is a set of declarations containing the declarations of all built-in objects, which are listed in Appendix A. Given a signature, one can built two kinds of terms|type terms and value terms. Type terms are terms that are built from type constructors and variables. Types are type terms that do not contain variables. Value terms are terms that are built from value constructors, functions, parameters, and variables. Values are value terms that are built from value constructors only, that is, do not contain functions, parameters, or variables. The built-in values of integer, char and string are nullary value constructors. Every module comes with three signatures: an export signature de ned by the interface of the module an import signature de ned by the interface of the module a local signature de ned by the body of the module. Since views don't have a body, they have only an import and an export signature. There are several consistency requirements for the signatures of modules and views, which are checked automatically. To de ne these requirements, we need several technical de nitions. This de nitions make sense only with respect to a given signature. We write s) t (read: s is directly outermost above t) if s and t are type terms and the pair (s; t) is an instance of a pair (u; v), where the signature contains a type de nition whose left-hand side is u and whose right-hand side contains v as a subtype speci cation. We write s ) t (read: s is outermost above t) if t is a type term and there exist n > 0 type terms s1; . . . ; sn such that s = s1 ) s2 ) ) sn = t: Given the signature that belongs to the subtype hierarchy in Figure 5.1, we have, for instance, int) int, group)int, group) posint, list(group))nelist(group), and list(group))elist. We say that a type constructor f is a subconstructor of a type constructor g, if there exist terms s1; . . . ; sm and variables x1; . . . ; xn such that g(x1; . . . ; xn) ) f(s1; . . . ; sm) and g(x1; . . . ; xn) is the left-hand side of a type de nition. We say that a type constructor f is a superconstructor of a type constructor g if g is a subconstructor of f . We write s ! t (read: s is directly above t) if t is a type term and s can be obtained from t by replacing a subterm u with v, where u) v. We write s t (read: s is above t) if s and t are type terms and there exist n > 0 type terms s1; . . . ; sn such that s = s1 ! s2 ! ! sn = t: We say that a type s is a subtype of a type t if t is above s. We say that a type s is a supertype of a type t if t is a subtype of s. Every type is a subtype and a supertype of itself. The in mum s u t of two type terms s and t is the greatest type term u such that s u and t u. The supremum s t t of two type terms s and t is the least type term u such that u s and u t. The consistency requirements we will discuss below ensure that is a partial order on type terms and that su t [s t t] exist if s and t have a common lower [upper] bound. Most of the following consistency requirements for signatures were already discussed informally in Section 2, which also gives counterexamples. A signature is closed, if every designator occurring in it has one and only one declaration, and every term occurring in one of its declarations as a type term is in fact a type term. A signature is well-founded, if there are no in nite chains