Introduction

The goal of the name resolver in the Clafer compiler is to determine which clafer in the model is referred to by a given reference by name. In a Clafer model, names can repeat as each clafer declaration includes a new namespace. For example, there can be many clafers called X in various places in the model. The clafer X can be referred to in these two ways:

1. as a super clafer: a : X (done in ResolveInheritance.hs), a -> X, and a ->> X (ResolveName.hs), and
2. inside expressions in constraints and goals: [ some X ], X + 1, and << max sum X.ref >>.

The name resolver decides which of the potentially multiple Xs is being referred to. Clafer X can be resolved as

• Special – this, parent, children, ref
• TypeSpecial – primitive type: integer, string, (need to add real, natural, etc.)
• Binding – local variable (in constraints with quantifier)
• Subclafers – in descendants (BFS)+ inheritance
• Reference – same as Subclafers + reachable via references
• Ancestor – in ancestors
• AbsClafer – abstract , top-level clafer
• TopClafer – concrete, top-level clafer

Currently (Clafer 0.3.3), the name resolver applies the following sequence of resolution strategies (in that exact order) given the current environment env and the clafer’s id:

resolve env id [resolveSpecial, resolveBind, resolveDescendants, resolveAncestor pos, resolveTopLevel pos, resolveNone pos]

The strategy resolveNone reports an error that the clafer with the given id was not found.

Test Cases

Resolving Special

• this refers to S1

• parent refers to S2

• children refers to a ++ b

S3
   a
   b
   [ children ]

results in resolver: unknown uid 'children'

Resolving TypeSpecial

• integer, string, real resolve to primitive types

interestRate -> real
interestRate -> double

results in resolver: real not found within and resolver: double not found within

Resolving Binding

• b in b.c resolves to b in b : B1. c in b.c resolves to B1.c via inheritance.

Resolving Subclafers

• b in some b resolves to a.b and not to a.b.b

Resolving Reference

• a in some a should resolve to A5.a

• B in -> A.B should resolve to A.B

refAB -> A.B *
  [ some B ]

results in an error B not found

Resolving Ancestor

• A1 in some A1 resolves to the top-level A1

• A2 in some A2 resolves to A2.A2 and not the top-level A2

A2 ?
  A2 ?
    B 
      [ some A2 ]

results in an unexplained compilation error.

Resolving AbsClafer

• Abs in : Abs, -> Abs, and ->> Abs resolves to abstract Abs

• nested abstract

Resolving TopClafer

• T in some T resolves to T ?

Resolving Redefinition

• (this affects name resolution for inheritance)

abstract A
	d 0..1

/* redefines A.d, narrows cardinality */

abstract B : A
	d 1..1 
		b ?

refA -> A

[ refA.ref.d.b ] this should produce error 'b' not found

refB -> B

[ refB.ref.d.b ] // this should work

Related BugBot Issues

• 231 name resolver should search through nested clafers
• 217 reference to nested clafers
• 216 inheritance among concrete clafers
• 206 Parent Required when Defining Ad-Hoc Set
• 169 No match in record selector sident
• 145 Quantify over union
• 95 children clafers not visible via reference to a reference
• 65 summary working with local clafers and global
• 60 add support for hierarchy specification and instantiation
• 48 add the lookup navigation operator to clafer

Issues 48 and 65 are just proposals, we have not decided yet.