Static Semantics

This section restricts the previously specified syntax of concrete programs to the set of statically well-defined concrete programs.

Firstly, we define the static semantics of type declarations. Each type in a concrete program must be defined by a type declaration.

Definition 3.31 The set of statically well-defined type declarations

TypeDecl is the set of all declarations of the form data T v1 . . . vm = C1 c11 . . . c1n1

. . .

| Ck ck1 . . . cknk

in TypeDeclSyntax with m ∈ N type variables v1, . . . , vm and k ∈ N>0

constructors C1, . . . , Ck, all of the following properties hold:

1. the arity of T equals the number of type variables, i.e., arity(T ) = m, 2. all constructors are pairwise distinct, i.e.,

∀(i, j) ∈ {1 . . . k}2_{: i ̸= j =⇒ C}

i ̸= Cj

3. the arity of each constructor equals the number of constructor argu- ments, i.e.,

∀i ∈ {1 . . . k} : ni= arity(Ci)

4. for all i ∈ {1 . . . k} and j ∈ {1 . . . ni}, the set of all variables appearing

in the constructor argument cij is a subset of {v1, . . . , vm}, and

5. for all i ∈ {1 . . . k} and j ∈ {1 . . . ni}, the type cij may not contain the

3.2. LANGUAGE OF CONCRETE PROGRAMS 33

Example 3.32 The following declaration for type Either is not included

in TypeDecl as the identifier c is no type variable of Either:

1 data Either a b = Left a | Right c

A type declaration that includes type variables defines a type operator [64]. Type operators may be applied to other types in order to construct new types. The set of types equals the set of terms over the signature of type constructors. See Appendix A.2 for a brief introduction to signatures and terms.

Definition 3.33 The set of statically well-defined types Type is defined as

the set of terms over TypeCon:

Type := terms(TypeCon, TypeVar)

Example 3.34 Assume the following type declarations that define a type

Bool and two type operators List and Either:

1 data Bool = False | True

2 data List a = Nil | Cons a (List a) 3 data Either a b = Left a | Right b

Here, List Bool ∈ Type but Either Bool /∈ Type because the type oper- ator Either has arity two but is only applied to one argument.

Throughout this thesis we often reference the constructors of a type declaration by their index.

Definition 3.35 The constructor index of a constructor C ∈ Con of a type

T ∈ Type is a positive natural number in N>0 denoting the position of C

in the sequence of constructors in the declaration of T .

Example 3.36 Assume the following type declaration that defines the type

Bool:

1 data Bool = False | True

For the type Bool, the constructor False has index 1, and the constructor True has index 2.

We introduce the set of fully instantiated types as the subset of Type that do not contain type variables.

Definition 3.37 The set of fully instantiated types Type0 ⊊ Type is the set of all types in Type that do not contain type variables:

Type0:= terms(TypeCon, ∅)

34 CHAPTER 3. SPECIFICATION OF CO4 Based on the previously defined set of types, we define the static semantics of type schemes:

Definition 3.39 The set of statically well-defined type schemes

TypeScheme is the set of all S ∈ SchemeSyntax such that all of the following properties hold for S:

1. each type that appears in S is included in Type, and

2. if S is of the form forall v1. . . vn : T for n ∈ N>0 and T ∈ Type,

then all type variables v1, . . . , vn ∈ TypeVar are pairwise distinct

and the set of type variables var(T ) that appears in T is a subset of {v1, . . . , vn}.

Example 3.40 forall x y : List z is no type scheme as the type variable

z is not bound by the quantifier.

We define the static semantics of patterns.

Definition 3.41 The set of statically well-defined patterns Pat is the set of

all C v1. . . vn ∈ PatSyntax with C ∈ Con and all variables v1, . . . , vn ∈

Var being pairwise distinct.

Example 3.42 Cons x xs ∈ Pat and Cons x x /∈ Pat. We define the static semantics of expressions.

Definition 3.43 The set of statically well-defined expressions Exp is the

set of all e ∈ ExpSyntax so that all of the following properties hold for e: 1. e is statically well-typed according to the Hindley–Damas–Milner type

inference [22] so that all type signatures are respected, 2. e does not contain an abstraction as a strict subexpression, 3. if e is an application,

(a) the application is total, i.e., the application of a n-ary function or constructor requires exactly n arguments for n ∈ N,

(b) no argument’s type may contain the type constructor ->, 4. if e is an abstraction \ v1. . . vn -> e′for n ∈ N>0, all variables v1, . . . , vn

∈ Var are pairwise distinct,

5. if e is a case distinction on a discriminant of type T ∈ Type,

(a) for each constructor C ∈ Con in T there is a corresponding pat- tern C v1. . . vn with n = arity(C) in the matches of e,

(b) no two patterns in the matches of e may contain the same con- structor,

3.2. LANGUAGE OF CONCRETE PROGRAMS 35

6. if e is a let expression that locally binds an expression e′ ∈ Exp, e′ may only depend on values that have been bound in an enclosing scope, or in the same let block, but before e′.

Note that property 2 allows abstractions to be included in Exp, but not as a strict subexpression of another expression.

Example 3.44 For all expressions e1, e2, · · · ∈ Exp and v1, v2, · · · ∈ Var,

the following expressions are not statically well-defined:

• \ v1-> v1v1 violates property 1 in Def. 3.43

• let v1 = \ v2-> e1 in e2 violates property 2 in Def. 3.43

• \ v1 v1-> e1 violates property 4 in Def. 3.43

• data Bool = False | True case e1 of False -> e2

False -> e3

violates property 5a and 5b in Def. 3.43

• let v1 = v2

v2 = v1

in e1

violates property 6 in Def. 3.43

The only requirement for statically well-defined matches is that each component must be statically well-defined as well.

Definition 3.45 The set of statically well-defined matches Match is the

set of all matches in MatchSyntax that contain a pattern from Pat and an expression from Exp.

Similarly, we define the static semantics of declarations in a concrete program.

Definition 3.46 The set of statically well-defined declarations Decl is the

set of all declarations in DeclSyntax that only contain statically well- defined types, expressions, and patterns.

Finally, we define the set of statically well-defined concrete programs.

Definition 3.47 The set of statically well-defined concrete programs Prog

is the set of all programs c ∈ ProgSyntax such that of the following prop- erties hold for c:

1. c only contains statically well-defined declarations, 2. c contains exactly one type declaration of the form

1 data Bool = False | True

3. c contains exactly one declaration of the form constraint = e with

36 CHAPTER 3. SPECIFICATION OF CO4 (a) e is of type P -> U -> Bool for some types P, U ∈ Type0,

(b) there is exactly one type declaration c for each of the types P and

U ,

4. each variable bound in c is only bound once, i.e., there are no two expressions that are bound to the same name.

The concrete program in Example 3.9 is statically well-defined.

Often we want to refer to the set of statically well-defined concrete programs that have a common type for their constraint declaration.

Definition 3.48 For the types P, U ∈ Type0, the set ProgP U denotes the

set of all concrete programs c ∈ Prog that contain a declaration of the form constraint = e with e ∈ Exp being of type P -> U -> Bool.