3.4 Constraint syntax
3.4.2 Syntactic forms
The set atoms(x) is defined to be a syntactic form set belonging to Var ∪ Label ∪ Dependency and occurring in x for some x.
Function are defined to extract variables, labels, and dependencies from a constraint term in figure 3.11.
Figure 3.11 Definition of sets of variables, labels and dependencies
vars(x) = atoms(x) ∩ Var (set of variables)
labs(x) = atoms(x) ∩ Label (set of labels)
3.5. SEMANTICS OF CONSTRAINTS/ENVIRONMENTS
3.4.3
Freshness
In this version of the core presentation dummy variables are used, which act like fresh variables. The definition of the dummy set is defined below:
Dum ::= {αdum, evdum, δdum}
Consider the environment (αdum = α1); (αdum = α2). In such an expression the
dummy variables are considered to be distinct from each other, and indeed from α1 and α2. A function nonDums is also defined which extracts all the variables in
a term while excluding the dummy variables. This is defined as follows:
nonDums(x) = vars(x)\Dum
3.5
Semantics of constraints/environments
The set of unifiers, renamings, and substitutions are defined in figure 3.12. Note that Ren ⊂ Unifier ⊂ Sub. Renamings are used to instantiate type schemes, and the Unifier set contains unifiers generated by the constraint solver (see section3.7). Sub- stitution is defined in figure3.13, where given a constraint term and a substitution, a resulting constraint term is produced.
Figure 3.12 Renaming, unifiers, and substitutions
ren ∈ Ren = {ren ∈ ITyVar → ITyVar | ren is injective
∧ dj(dom(ren), ran(ren))}
u ∈ Unifier = {f1∪ f2∪ f3 | f1 ∈ ITyVar → ITy
∧ f2∈ TyConVar → ITyCon
∧ f3 ∈ EnvVar → Env}
sub ∈ Sub = {f1∪ f2 | f1∈ Unifier ∧ f2 ∈ TyConName → TyConName}
∆ ∈ Context ::= hu, ei
Defined also are constraint solving contexts ∆. Such contexts are used during constraint solving and consist of the unifiers and an environment as a tuple. Also, hu, ei(v ) is written to represent u(v ) and hu, ei; e0 to represent hu, e; e0i.
3.5.1
Shadowing
In the environment portion of a constraint solving context it may be the case that some parts are inaccessible. For example, in the following constraint solving context:
3.5. SEMANTICS OF CONSTRAINTS/ENVIRONMENTS
Figure 3.13 Substitution semantics
v [sub] =
x, if sub(v ) = x v , otherwise
(τ µ)[sub] = τ [sub] µ[sub]
(τ1 τ2)[sub] = τ1[sub] τ2[sub]
xd[sub] = x[sub]d
(x1= x2)[sub] = (x1[sub] = x2[sub])
(e1;e2)[sub] = e1[sub];e2[sub]
(∀v . x)[sub] = ∀v . x[sub] s.t. dj(v , atoms(sub)) (id =v )[sub ] =
(id =v [sub ]), if v [sub] ∈ Var
undefined, otherwise
(id =x)[sub ] = (id =x[sub ])
poly(e)[sub] = poly(e[sub])
x[sub] = x, otherwise
hu, bind1; ev; bind2i
if ev /∈ dom(u), it is said that ev shadows bind1 because ev could potentially be
bound to an environment which rebinds bind1. The predicate shadowsAll is defined
below. shadowsAll(hu, ei) ⇐⇒
(e = ev ∧ (shadowsAll(hu, u(ev )i) ∨
ev 6∈ dom(u))) ∨ (e = (e1;e2) ∧ (shadowsAll(hu, e1i) ∨
shadowsAll(hu, e2i)))
∨ (e = he0, d i ∧ shadowsAll(hu, e0i))
shadowsAll(e) ⇐⇒ shadowsAll(h∅, ei)
Below presents how to access the semantics of an identifier in a constraint solving context.
hu, (id =x)i(id ) = x
hu, (ed)i(id ) = collapse(hu, ei(id )d)
hu, (e1;e2)i(id ) =
(
x, ifhu, e2i(id ) = x or shadowsAll(hu, e2i)
hu, e1i(id ), otherwise
hu, ev i(id ) =
(
hu, ei(id ), if u(ev ) = e undefined, otherwise
e(id ) = h∅, ei(id)
3.5.2
Relations
Two instance relations are defined here, the use of which can be seen in constraint solving.
3.6. CONSTRAINT GENERATION
x −−−−−−instance→ yd[sub], if collapse(x∅) = (∀v
0.y)d and dom(sub) = v0
x −−−−−−instance→ x, if collapse(x∅) is not of the form (∀v0.y)d
3.6
Constraint generation
The initial constraint generator is defined in figure 4.17. This is referred to as the initial constraint generator because constraints are also generated during the constraint solving process (section 4.4).
In this presentation the relation _ is used which is the smallest relation satisfying the rules in the constraint generator.
The rules in figure 3.14 return either an environment e, or something of the form hv , ei, where e constraints the variable v .
It can be seen that datatype declarations only have one constructor by looking at rules (G18), (G14) and (G16). The core has been defined in this manner in order to reduce its complexity. In rule (G13) the datatype names are defined to have exactly one type variable argument.
Structure declarations are handled in rule (G20). In the core, signatures to constrain these structures are not presented, but this extension to the core can be found in section6.4.
In order that environments can be sliced out correctly, environment variables are annotated with labels, such as in rule (G4). Such environment variables must be annotated with a label otherwise they could not be sliced out, and that environment variable would then shadow any following environment, even if the program point the label was assigned to was itself sliced out.
3.6. CONSTRAINT GENERATION
Figure 3.14 Initial constraint generator
All rules of the form P ⇐⇐⇐ Q have to be read as P ⇐⇐⇐ (Q ∧∧∧ dja(e, e1, e2, α, α0, ev , ev0))
Expressions (exp -. hα, ei) (G1) vidle -. hα,vid = αil
(G2) letldec in exp end -. hα, [e1; e2; (α l
= α2)]i ⇐⇐⇐ dec -. e1∧ exp -. hα2, e2i
(G3) dexp atexpel -. hα, [e1; e2; (α l
= α1→ α2)]i ⇐⇐⇐ exp -. hα, e1i ∧ atexp -. hα2, e2i
(G4) fn pat ⇒ exp -. hα, [(ev = el 1); evl; e2; (α l
= α1 → α2)]i ⇐⇐⇐ pat -. hα1, e1i ∧ exp -.
hα2, e2i
Labelled datatype constructors (ldcon -. hα, ei) (G5) dconl -. hα,dcon= αil
Patterns(pat -. hα, ei) (G6) vvarlp -. hα,vvar = αil (G7) dconlp-. hα,dcon= αil (G8) dldcon atpat el -. hα, e
1; e2; (α1 l
= α2 → α)i ⇐⇐⇐ ldcon -. hα1, e1i ∧ atpat -. hα2, e2i
Labelled type constructors (ltc -. hδ, ei) (G9) tcl -. hδ,tc = δil
Types(ty -. hα, ei) (G10) tvl -. hα,tv = αil
(G11) dty ltcel -. hα0, e1; e2; (α0 l= αδ)i ⇐⇐⇐ ty1 -. hα1, e1i ∧ ltc -. hδ, e2i
(G12) α1 α2 -. hα, e1; e2; (α
l
= α1 → α2)i ⇐⇐⇐ ty1 -. hα1, e1i ∧ ty2 -. hα2, e2i
Datatype names(dn -. hα, ei)
(G13) dtv tcel -. hα0, (α0 l= αγ); (tc= γ); (l tv = α)i ⇐l ⇐⇐ α 6= α0
Constructor bindings (cb -. hα, ei) (G14) dconlc -. hα,dcon= αil
(G16) dcon oflty -. hα, e1; (α0 l= α1→ α); (α0 l= α1 α); (dcon
l
= α0)i ⇐⇐⇐ ty -. hα1, e1i
Declarations (dec -. e)
(G17) val rec pat = exp -. (ev = poly(el 1; e2; (α1 l
= α2))); evl ⇐⇐⇐ pat -. hα1, e1i ∧ exp -.
hα2, e2i
(G18) datatype dn = cb -. (ev = ((αl 1= αl 2); e1; poly(e2))); evl ⇐⇐⇐ dn -. hα1, e1i ∧ cb -.
hα2, e2i
(G19) openl strid -. (strid
l
= ev ); evl Structure declarations (strdec -. e)
(G20) structure strid = strexp -. [e]; (evl 0 = (strid= ev )); evl 0l ⇐⇐⇐ strexp -. hev , ei Structure expressions (strexp -. hev , ei)
(G21) stridl -. hev ,
strid
l
= ev i
(G22) structl strdec1· · · strdecn end -. hev , (ev l
= ev0); (ev0= (e1; ...; en))i
3.6. CONSTRAINT GENERATION
Each of the constraint generation rules are now discussed in turn.
3.6.1
Expressions
Rule (G1) generates accessors for value identifiers. For example, where a function previously defined is applied to an argument, the accessor which connects the use of this function to its definition is generated.
Rule (G2) handles let expressions, where some declarations are to be defined in the scope of some expression. We accomplish this with the [e] notation - by encasing the environments from the declaration inside square brackets, upon closing of these brackets that environment is not exported (as described previously) and so binders inside are not available to following expressions.
Applications are handled with rule (G3). Here the → piece of constraint syntax is used to represent the expression part being used as a function.
Nameless functions are handled in rule (G4). We label the environment variable in this rule (and similarly in other rules) in order that declarations which have been sliced out do not shadow their context. If the environment variable was not labelled, then it would shadow the context it was in irrespective if some environment was sliced out or not.