Name binding with scope graphs

Declare Your Language
Part 2: Name Binding with Scope Graphs
Eelco Visser
Tutorial at POPL 2016
January 18, 2016

Static Name Resolution
module A {
def s = 5
}
module B {
import A
def x = 6
def y = 3 + s
def f =
fun x { x + y }
}

Static Name Resolution
module module
def import def def defA
A
B
6 y funf
x +
x y
x +
3 s
5s
module A {
def s = 5
}
module B {
import A
def x = 6
def y = 3 + s
def f =
fun x { x + y }
}

Based On …
• Declarative Name Binding and Scope Rules
- NaBL name binding language
- Gabriël D. P. Konat, Lennart C. L. Kats, Guido Wachsmuth, Eelco Visser
- SLE 2012
• A Language Designer's Workbench
- A one-stop-shop for implementation and veriﬁcation of language designs
- Eelco Visser, Guido Wachsmuth, Andrew P. Tolmach, Pierre Neron, Vlad A. Vergu,
Augusto Passalaqua, Gabriël D. P. Konat
- Onward 2014
• A Theory of Name Resolution
- Pierre Néron, Andrew Tolmach, Eelco Visser, Guido Wachsmuth
- ESOP 2015
• A Constraint Language for Static Semantic Analysis based on Scope
Graphs
- Hendrik van Antwerpen, Pierre Neron, Andrew P. Tolmach, Eelco Visser, Guido
Wachsmuth
- PEPM 2016

Detour:
Declare Your Syntax
(an analogy for formalizing declarative name binding)
Pure and declarative syntax deﬁnition: paradise lost and regained
Lennart C. L. Kats, Eelco Visser, Guido Wachsmuth
Onward 2010

Language = Set of Sentences
fun (x : Int) { x + 1 }
Text is a convenient interface for writing and reading programs

Language = Set of Trees
Fun
AddArgDecl
VarRefId Int
“1”
VarDeclId
“x”
TXINT
“x”
Tree is a convenient interface for transforming programs

Tree Transformation
Tree is a convenient interface for transforming programs
Semantic
transform
translate
eval
analyze
refactor
type check
Syntactic
coloring
outline view
completion

Language = Sentences and Trees
parse
format
different representations convenient for different purposes

SDF3 deﬁnes Trees and Sentences
parse(s) = t where format(t) == s (modulo layout)
Expr.Int = INT
Expr.Add = <<Expr> + <Expr>>
Expr.Mul = <<Expr> * <Expr>>
trees
(structure)
parse
(text to tree)
format
(tree to text)
+ =>

Grammar Engineering in Spoofax

Ambiguity
t1 != t2 / format(t1) = format(t2)
Add
VarRef VarRef
“y”“x”
Mul
Int
“3”
Add
VarRef
VarRef
“y”
“x”
Mul
Int
“3”
3 * x + y

Declarative Disambiguation
parse ﬁlter
Disambiguation Filters
Klint & Visser (1994), Van den Brand, Scheerder, Vinju, Visser (CC 2002)

Priority and Associativity
context-free syntax
Expr.Int = INT
Expr.Add = <<Expr> + <Expr>> {left}
Expr.Mul = <<Expr> * <Expr>> {left}
context-free priorities
Expr.Mul > Expr.Add
Recent improvement: safe disambiguation of operator precedence
Afroozeh et al. (SLE 2013, Onward 2015)
Add
VarRef VarRef
“y”“x”
Mul
Int
“3”
Add
VarRef
VarRef
“y”
“x”
Mul
Int
“3”
3 * x + y

Declarative Syntax Definition
• Representation: (Abstract Syntax) Trees
- Standardized representation for structure of programs
- Basis for syntactic and semantic operations
• Formalism: Syntax Definition
- Productions + Constructors + Templates + Disambiguation
- Language-specific rules: structure of each language construct
• Language-Independent Interpretation
- Well-formedness of abstract syntax trees
‣ provides declarative correctness criterion for parsing
- Parsing algorithm
‣ No need to understand parsing algorithm
‣ Debugging in terms of representation
- Formatting based on layout hints in grammar

Declare Your Names
A Theory of Name Resolution
Pierre Néron, Andrew Tolmach, Eelco Visser, Guido Wachsmuth
ESOP 2015

Language = Set of Graphs
Fun
AddArgDecl
VarRefId Int
“1”
VarDeclId TXINT
Edges from references to declarations

Fun
AddArgDecl
VarRefId Int
“1”
VarDeclId
“x”
TXINT
“x”
Language = Set of Graphs
Names are placeholders for edges in linear / tree representation

Name Resolution is Pervasive
• Used in many different language artifacts
- compiler
- interpreter
- semantics
- IDE
- refactoring
• Binding rules encoded in many different and ad-hoc ways
- symbol tables
- environments
- substitutions
• No standard approach to formalization
- there is no BNF for name binding
• No reuse of binding rules between artifacts
- how do we know substitution respects binding rules?

NaBL Name Binding Language
binding rules // variables
Param(t, x) :
defines Variable x of type t
Let(bs, e) :
scopes Variable
Bind(t, x, e) :
defines Variable x of type t
Var(x) :
refers to Variable x
Declarative Name Binding and Scope Rules
Gabriël D. P. Konat, Lennart C. L. Kats, Guido Wachsmuth, Eelco Visser
SLE 2012
Declarative speciﬁcation
Abstracts from implementation
Incremental name resolution
But:
How to explain it to Coq?
What is the semantics of NaBL?

NaBL Name Binding Language
Declarative Name Binding and Scope Rules
Gabriël D. P. Konat, Lennart C. L. Kats, Guido Wachsmuth, Eelco Visser
SLE 2012
Especially:
What is the semantics of imports?
binding rules // classes
Class(c, _, _, _) :
defines Class c of type ClassT(c)
scopes Field, Method, Variable
Extends(c) :
imports Field, Method from Class c
ClassT(c) :
refers to Class c
New(c) :
refers to Class c

A Theory of Name Resolution
• Representation: Scope Graphs
- Standardized representation for lexical scoping structure of programs
- Path in scope graph relates reference to declaration
- Supports ambiguous / erroneous programs
• Formalism: Name Binding Speciﬁcation
- References + Declarations + Scopes + Reachability + Visibility
- Language-speciﬁc rules: mapping constructs to scope graph
- Resolution calculus
‣ Correctness of path with respect to scope graph
‣ Separation of reachability and visibility (disambiguation)
- Name resolution algorithm
‣ sound wrt calculus
- Transformation
‣ Alpha equivalence, substitution, refactoring, …

Outline
• Reachability
- References, Declarations, Scopes, Resolution Paths
- Lexical, Imports, Qualiﬁed Names
• Visibility
- Ambiguous resolutions
- Disambiguation: path speciﬁcity, path wellformedness
• Examples
- let, def-before-use, inheritance, packages, imports, namespaces
• Formal framework
- Generalizing reachability and visibility through labeled scope edges
- Resolution algorithm
- Alpha equivalence
• Names and Types
- Type-dependent name resolution
• Constraint Language

Reachability
(Slides by Pierre Néron)

A Calculus for Name Resolution
S R1 R2 SR
SRS
I(R1)
S’S
S’S P
Sx
Sx R
xS
xS D
Path in scope graph connects reference to declaration
Scopes, References, Declarations, Parents, Imports

Simple Scopes
def y1 = x2 + 1
def x1 = 5

Simple Scopes
S0
def y1 = x2 + 1
def x1 = 5

Simple Scopes
Scope
S0
def y1 = x2 + 1
def x1 = 5
S0
S

Simple Scopes
Declaration
Scope
S0
def y1 = x2 + 1
def x1 = 5
y1
x1S0
S
x

Simple Scopes
Reference
Declaration
Scope
S0
def y1 = x2 + 1
def x1 = 5
y1
x1S0x2
S
x
x

Simple Scopes
Reference
Declaration
Scope
Reference Step
S0
def y1 = x2 + 1
def x1 = 5
Sx
Sx R
y1
x1S0x2
S
x
x

Simple Scopes
Reference
Declaration
Scope
Reference Step
S0
def y1 = x2 + 1
def x1 = 5
Sx
Sx R
R
y1
x1S0x2
S
x
x

Simple Scopes
Reference
Declaration
Scope
Reference Step Declaration Step
S0
def y1 = x2 + 1
def x1 = 5
Sx
Sx R
xS
xS D
R
y1
x1S0x2
S
x
x

Simple Scopes
Reference
Declaration
Scope
Reference Step Declaration Step
S0
def y1 = x2 + 1
def x1 = 5
Sx
Sx R
xS
xS D
R D
y1
x1S0x2
S
x
x

Lexical Scoping
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}

Lexical Scoping
S0
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}

Lexical Scoping
S1
S0
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}

Lexical Scoping
S1
S0
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
z1
x1S0z2

Lexical Scoping
S1
S0
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S1
y1y2 x2
z1
x1S0z2

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S1
y1y2 x2
z1
x1S0z2
S’S

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S1
y1y2 x2
z1
x1S0z2
R
S’S

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S1
y1y2 x2
z1
x1S0z2
R
D
S’S

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S’S
S’S P
S1
y1y2 x2
z1
x1S0z2
R
S’S
Parent Step

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S’S
S’S P
S1
y1y2 x2
z1
x1S0z2
R
P
S’S
Parent Step

Lexical Scoping
S1
S0
Parent
def x1 = z2 5
def z1 =
fun y1 {
x2 + y2
}
S’S
S’S P
S1
y1y2 x2
z1
x1S0z2
R
P
D
S’S
Parent Step

Imports
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}

Imports
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
A1
SA
z1
B1
SB
z2
S0
A2
x1

Imports
Associated scope
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
R

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
R
S R1 R2 SR
SRS
I(R1)
Import Step

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
R
R
S R1 R2 SR
SRS
I(R1)
Import Step

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
R
R
P
S R1 R2 SR
SRS
I(R1)
Import Step

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
R
R
P
D
S R1 R2 SR
SRS
I(R1)
Import Step

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R
R
P
D
S R1 R2 SR
SRS
I(R1)
Import Step

Imports
Associated scope
Import
S0
SB
SA
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
S R1
R2 SR
A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R
R
D
P
D
S R1 R2 SR
SRS
I(R1)
Import Step

Qualiﬁed Names
module N1 {
def s1 = 5
}
module M1 {
def x1 = 1 + N2.s2
}
S0

Qualiﬁed Names
module N1 {
def s1 = 5
}
module M1 {
def x1 = 1 + N2.s2
}
S0
N1
SN
s2
S0
N2
X1
s1

Qualiﬁed Names
module N1 {
def s1 = 5
}
module M1 {
def x1 = 1 + N2.s2
}
S0
N1
SN
s2
S0
N2
R
D
X1
s1

Qualiﬁed Names
module N1 {
def s1 = 5
}
module M1 {
def x1 = 1 + N2.s2
}
S0
N1
SN
s2
S0
N2
R
D
R
I(N2) D
X1
s1

S R1 R2 SR
SRS
I(R1)
S’S
S’S P
Sx
Sx R
xS
xS D
Reachability of declarations from references
through scope graph edges
How about ambiguities?
References with multiple paths

Visibility
(Disambiguation)
(Slides by Pierre Néron)

S R1 R2 SR
SRS
I(R1)
S’S
S’S P
Sx
Sx R
xS
xS D
I(_).p’ < P.p
D < I(_).p’
D < P.p
s.p < s.p’
p < p’
Reachability
VisibilityWell formed path: R.P*.I(_)*.D

Ambiguous Resolutions
S0def x1 = 5
def x2 = 3
def z1 = x3 + 1

z1
x2
x1S0x3
S0def x1 = 5
def x2 = 3
def z1 = x3 + 1

z1
x2
x1S0x3
RS0def x1 = 5
def x2 = 3
def z1 = x3 + 1

z1
x2
x1S0x3
R DS0def x1 = 5
def x2 = 3
def z1 = x3 + 1

z1
x2
x1S0x3
R
D
S0def x1 = 5
def x2 = 3
def z1 = x3 + 1

z1
x2
x1S0x3
R D
D
S0def x1 = 5
def x2 = 3
def z1 = x3 + 1

match t with
| A x | B x => …
z1
x2
x1S0x3
R D
D
S0def x1 = 5
def x2 = 3
def z1 = x3 + 1

Shadowing
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}

Shadowing
S0
S1
S2
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}

Shadowing
S0
S1
S2
S1
S2
x1
y1
y2 x2
z1
x3S0z2
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}

Shadowing
S0
S1
S2
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}
S1
S2
x1
y1
y2 x2
z1
x3S0z2
R
P
P
D

Shadowing
S0
S1
S2
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}
S1
S2
x1
y1
y2 x2
z1
x3S0z2
D
P
R
R
P
P
D

Shadowing
S0
S1
S2
D < P.p
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}
S1
S2
x1
y1
y2 x2
z1
x3S0z2
D
P
R
R
P
P
D

Shadowing
S0
S1
S2
D < P.p
s.p < s.p’
p < p’
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}
S1
S2
x1
y1
y2 x2
z1
x3S0z2
D
P
R
R
P
P
D

Shadowing
S0
S1
S2
D < P.p
s.p < s.p’
p < p’
def x3 = z2 5 7
def z1 =
fun x1 {
fun y1 {
x2 + y2
}
}
S1
S2
x1
y1
y2 x2
z1
x3S0z2
D
P
R
R
P
P
D
R.P.D < R.P.P.D

Imports shadow Parents
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

A1
SA
z1
B1
SB
z2
S0
A2
x1
z3
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R D
z3
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R D
P
D
z3
R
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

I(_).p’ < P.p
A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R D
P
D
z3
R
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

I(_).p’ < P.p R.I(A2).D < R.P.D
A1
SA
z1
B1
SB
z2
S0
A2
x1
I(A2
)R D
P
D
z3
R
S0def z3 = 2
module A1 {
def z1 = 5
}
module B1 {
import A2
def x1 = 1 + z2
}
SA
SB

Imports vs. Includes
S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA

S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA A1
SA
z1
z2
S0
A2
x1z3

S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA A1
SA
z1
z2
S0
A2
x1
R
z3
D

S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D

S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D
D < I(_).p’

S0def z3 = 2
module A1 {
def z1 = 5
}
import A2
def x1 = 1 + z2
SA A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D
D < I(_).p’
R.D < R.I(A2).D

A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D
D < I(_).p’
R.D < R.I(A2).D
S0def z3 = 2
module A1 {
def z1 = 5
}
include A2
def x1 = 1 + z2
SA

A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D
D < I(_).p’
R.D < R.I(A2).D
S0def z3 = 2
module A1 {
def z1 = 5
}
include A2
def x1 = 1 + z2
SA
X

A1
SA
z1
z2
S0
A2
x1
I(A2
)
R
D
z3
R
D
D < I(_).p’
S0def z3 = 2
module A1 {
def z1 = 5
}
include A2
def x1 = 1 + z2
SA
X

Import Parents
def s1 = 5
module N1 {
}
def x1 = 1 + N2.s2
S0
SN

Import Parents
def s1 = 5
module N1 {
}
def x1 = 1 + N2.s2
S0
SN
N1
SN
s2
S0
N2
X1
s1

Import Parents
def s1 = 5
module N1 {
}
def x1 = 1 + N2.s2
S0
SN
N1
SN
s2
S0
N2
X1
s1
R
I(N2)
D
P

Import Parents
def s1 = 5
module N1 {
}
def x1 = 1 + N2.s2
S0
SN
Well formed path: R.P*.I(_)*.D
N1
SN
s2
S0
N2
X1
s1
R
I(N2)
D
P

Transitive vs. Non-Transitive
module A1 {
def z1 = 5
}
module B1 {
import A2
}
module C1 {
import B2
def x1 = 1 + z2
}
SA
SB
SC

??
module A1 {
def z1 = 5
}
module B1 {
import A2
}
module C1 {
import B2
def x1 = 1 + z2
}
SA
SB
SC

A1
SA
z1
B1
SB
S0
A2
C1
SCz2
x1 B2
??
module A1 {
def z1 = 5
}
module B1 {
import A2
}
module C1 {
import B2
def x1 = 1 + z2
}
SA
SB
SC

A1
SA
z1
B1
SB
S0
A2
I(A2
)
D
C1
SCz2
I(B2
)
R
x1 B2
??
module A1 {
def z1 = 5
}
module B1 {
import A2
}
module C1 {
import B2
def x1 = 1 + z2
}
SA
SB
SC

With transitive imports, a well formed path is R.P*.I(_)*.D
With non-transitive imports, a well formed path is R.P*.I(_)?
.D
A1
SA
z1
B1
SB
S0
A2
I(A2
)
D
C1
SCz2
I(B2
)
R
x1 B2
??
module A1 {
def z1 = 5
}
module B1 {
import A2
}
module C1 {
import B2
def x1 = 1 + z2
}
SA
SB
SC

Examples
(From TUD-SERG-2015-001. Adapted for this screen)

Let Bindings
1
2
b2a1 c3
a4
b6
c12a10 b11
c5
b9
a7
c8
def a1 = 0
def b2 = 1
def c3 = 2
letpar
a4 = c5
b6 = a7
c8 = b9
in
a10+b11+c12
1
b2a1 c3
a4
b6
c12a10 b11
c5
b9
a7
c8
2
def a1 = 0
def b2 = 1
def c3 = 2
letrec
a4 = c5
b6 = a7
c8 = b9
in
a10+b11+c12
1
b2a1 c3
a4
b6
c12a10 b11
c5
b9
a7
c8
2
4
3
def a1 = 0
def b2 = 1
def c3 = 2
let
a4 = c5
b6 = a7
c8 = b9
in
a10+b11+c12

Deﬁnition before Use / Use before Deﬁnition
class C1 {
int a2 = b3;
int b4;
void m5 (int a6) {
int c7 = a8 + b9;
int b10 = b11 + c12;
}
int c12;
}
0 C1
1
2
a2
b4
c12
b3
m5
a6
3
4
c7
b10
b9
a8
b11 c12

Inheritance
class C1 {
int f2 = 42;
}
class D3 extends C4 {
int g5 = f6;
}
class E7 extends D8 {
int f9 = g10;
int h11 = f12;
}
32
1
C4
C1
4D3
E7
D8
f2 g5 f6
f9
g10
f12
h11

Java Packages
package p3;
class D4 {}
package p1;
class C2 {}
1 p3p1
2
p1 p3
3
D4C2

Java Import
package p1;
imports r2.*;
imports q3.E4;
public class C5 {}
class D6 {}
4
p1
D6C5
3
2r2
1
p1
E4
q3

C# Namespaces and Partial Classes
namespace N1 {
using M2;
partial class C3 {
int f4;
}
}
namespace N5 {
partial class C6 {
int m7() {
return f8;
}
}
}
1
3 6
4 7
8
C3 C6
N1 N5
f4 m7
N1 N5
C3 C6
f8
2 M2 5

More Examples?
Here the audience proposes binding patterns that they
think are not covered by the scope graph framework
(and they may be right?)

Formal Framework
(with labeled scope edges)

Issues with the Reachability Calculus
S R1 R2 SR
SRS
I(R1)
S’S
S’S P
Sx
Sx R
xS
xS D
I(_).p’ < P.p
D < I(_).p’
D < P.p
s.p < s.p’
p < p’
Well formed path: R.P*.I(_)*.D
Disambiguating import paths
Fixed visibility policy
Cyclic Import Paths
Multi-import interpretation

Resolution Calculus with Edge Labels
s the resolution relation for graph G.
collection JNKG is the multiset defined
DG(S)), JR(S)KG = ⇡(RG(S)), and
`G p : S 7 ! xD
i }) where ⇡(A) is
ojecting the identifiers from a set A of
iven a multiset M, 1M (x) denotes the
nes the resolution of a reference to a
as a most specific, well-formed path
n through a sequence of edges. A path
ng the atomic scope transitions in the
of steps:
l, S2) is a direct transition from the
pe S2. This step records the label of
s used.
, yR
, S) requires the resolution of ref-
n with associated scope S to allow a
rrent scope and scope S.
nds with a declaration step D(xD
) that
path is leading to.
ion in the graph from reference xR
i
`G p : xR
i 7 ! xD
i according to
. These rules all implicitly apply to
omit to avoid clutter. The calculus
n in terms of edges in the scope graph,
isible declarations. Here I is the set of
vice needed to avoid “out of thin air”
Well-formed paths
WF(p) , labels(p) 2 E
Visibility ordering on paths
label(s1) < label(s2)
s1 · p1 < s2 · p2
p1 < p2
s · p1 < s · p2
Edges in scope graph
S1
l
S2
I ` E(l, S2) : S1 ! S2
(E)
S1
l
yR
i yR
i /2 I I ` p : yR
i 7 ! yD
j yD
j S2
I ` N(l, yR
i , S2) : S1 ! S2
(N)
Transitive closure
I, S ` [] : A ⇣ A
(I)
B /2 S I ` s : A ! B I, {B} [ S ` p : B ⇣ C
I, S ` s · p : A ⇣ C
(T)
Reachable declarations
I, {S} ` p : S ⇣ S0
WF(p) S0
xD
i
I ` p · D(xD
i ) : S ⇢ xD
i
(R)
Visible declarations
I ` p : S ⇢ xD
i
8j, p0
(I ` p0
: S ⇢ xD
j ) ¬(p0
< p))
I ` p : S 7 ! xD
i
(V )
Reference resolution
xR
i S {xR
i } [ I ` p : S 7 ! xD
j
I ` p : xR
i 7 ! xD
j
(X)
G, |= !N
JN1KG ✓ JN2KG
G, |= N1
⇢
⇠ N2
(C-SUBNAME)
t1 = t2
G, |= t1 ⌘ t2
(C-EQ)
Figure 8. Interpretation of resolution and typing constraints
Resolution paths
s := D(xD
i ) | E(l, S) | N(l, xR
i , S)
p := [] | s | p · p (inductively generated)
[] · p = p · [] = p
(p1 · p2) · p3 = p1 · (p2 · p3)
Well-formed paths
WF(p) , labels(p) 2 E
Visibility ordering on paths
label(s1) < label(s2)
s1 · p1 < s2 · p2
p1 < p2
s · p1 < s · p2
Edges in scope graph
S1
l
S2
I ` E(l, S2) : S1 ! S2
(E)
S1
l
yR
i yR
i /2 I I ` p : yR
i 7 ! yD
j yD
j S2
I ` N(l, yR
i , S2) : S1 ! S2
(N)
Transitive closure
I, S ` [] : A ⇣ A
(I)
B /2 S I ` s : A ! B I, {B} [ S ` p : B ⇣ C
I, S ` s · p : A ⇣ C
(T)
Reachable declarations
I, {S} ` p : S ⇣ S0
WF(p) S0
xD
i
I ` p · D(xD
i ) : S ⇢ xD
i
(R)
Visible declarations
I ` p : S ⇢ xD
i
8j, p0
(I ` p0
: S ⇢ xD
j ) ¬(p0
< p))
I ` p : S 7 ! xD
i
(V )
Reference resolution
xR
S {xR
} [ I ` p : S 7 ! xD
C := CG
| CTy | CRes | C ^ C | True
CG
:= R S | S D | S l
S | D S | S l
R
CRes := R 7! D | D S | !N | N ⇢
⇠ N
CTy := T ⌘ T | D : T
D := | xD
i
R := xR
i
S := & | n
T := ⌧ | c(T, ..., T) with c 2 CT
N := D(S) | R(S) | V(S)
Figure 7. Syntax of constraints
scope graph resolution calculus (described in Section 3.3). Finally,
we apply |= with G set to CG
.
To lift this approach to constraints with variables, we simply
apply a multi-sorted substitution , mapping type variables ⌧ to
ground types, declaration variables to ground declarations and
scope variables & to ground scopes. Thus, our overall definition of
satisfaction for a program p is:
(CG
), |= (CRes
) ^ (CTy
) (⇧)

Visibility Policies
Lexical scope
L := {P} E := P⇤
D < P
Non-transitive imports
L := {P, I} E := P⇤
· I?
D < P, D < I, I < P
Transitive imports
L := {P, TI} E := P⇤
· TI⇤
D < P, D < TI, TI < P
Transitive Includes
L := {P, Inc} E := P⇤
· Inc⇤
D < P, Inc < P
Transitive includes and imports, and non-transitive imports
L := {P, Inc, TI, I} E := P⇤
· (Inc | TI)⇤
· I?
D < P, D < TI, TI < P, Inc < P, D < I, I < P,
Figure 10. Example reachability and visibility policies by instan-
tiation of path well-formedness and visibility.
3.4 Parameterization
R
Envre [
EnvL
re [
EnvD
re [
Envl
re [
I

Seen Imports
hout import tracking.
ficity order on paths is
e visibility policies can
e and specificity order.
module A1 {
module A2 {
def a3 = ...
}
}
import A4
def b5 = a6
Fig. 11. Self im-
port
tion
the
dule
far,
few
!
t A4
ody
?
13
AD
2 :SA2 2 D(SA1 )
AR
4 2 I(Sroot)
AR
4 2 R(Sroot) AD
1 :SA1 2 D(Sroot)
AR
4 7 ! AD
1 :SA1
Sroot ! SA1 (⇤)
Sroot ⇢ AD
2 :SA2
AR
4 2 R(Sroot) Sroot 7 ! AD
2 :SA2
AR
4 7 ! AD
2 :SA2
Fig. 10. Derivation for AR
4 7 ! AD
2 :SA2 in a calculus without import tracking.
The complete definition of well-formed paths and specificity order on paths is
given in Fig. 2. In Section 2.5 we discuss how alternative visibility policies can
be defined by just changing the well-formedness predicate and specificity order.
module A1 {
module A2 {
def a3 = ...
}
}
import A4
def b5 = a6
Seen imports. Consider the example in Fig. 11. Is declaration
a3 reachable in the scope of reference a6? This reduces to the
question whether the import of A4 can resolve to module
A2. Surprisingly, it can, in the calculus as discussed so far,
as shown by the derivation in Fig. 10 (which takes a few
shortcuts). The conclusion of the derivation is that AR
4 7 !
AD
:S . This conclusion is obtained by using the import at A
as shown by the derivation in Fig. 10 (which takes
shortcuts). The conclusion of the derivation is that AR
4
AD
2 :SA2 . This conclusion is obtained by using the import
to conclude at step (*) that Sroot ! SA1
, i.e. that the
of module A1 is reachable! In other words, the import
is used in its own resolution. Intuitively, this is nonsen
To rule out this kind of behavior we extend the cal
to keep track of the set of seen imports I using judgem
of the form I ` p : xR
i 7 ! xD
j . We need to extend all ru
pass the set I, but only the rules for resolution and im
are truly affected:
xR
i 2 R(S) {xR
i } [ I ` p : S 7 ! xD
j
I ` p : xR
i 7 ! xD
j
yR
i 2 I(S1) I I ` p : yR
i 7 ! yD
j :S2
I ` I(yR
i , yD
j :S2) : S1 ! S2
With this final ingredient, we reach the full calcul

4
def b5 = a6
Fig. 11. Self im-
port
module A1 {
module B2 {
def x3 = 1
}
}
module B4 {
module A5 {
def y6 = 2
}
}
module C7 {
import A8
import B9
def z10 = x11
+ y12
}
Fig. 12. Anoma-
lous resolution
. The conclusion of the derivation is that AR
4 7 !
This conclusion is obtained by using the import at A4
de at step (*) that Sroot ! SA1
, i.e. that the body
A1 is reachable! In other words, the import of A4
its own resolution. Intuitively, this is nonsensical.
e out this kind of behavior we extend the calculus
ack of the set of seen imports I using judgements
m I ` p : xR
i 7 ! xD
j . We need to extend all rules to
et I, but only the rules for resolution and import
aﬀected:
xR
i 2 R(S) {xR
i } [ I ` p : S 7 ! xD
j
I ` p : xR
i 7 ! xD
j
(X)
yR
i 2 I(S1) I I ` p : yR
i 7 ! yD
j :S2
I ` I(yR
i , yD
j :S2) : S1 ! S2
(I)
this ﬁnal ingredient, we reach the full calculus in
is not hard to see that the resolution relation is
ded. The only recursive invocation (via the I rule)
ictly larger set I of seen imports (via the X rule); since the set R(G)
Anomaly
4
def b5 = a6
Fig. 11. Self im-
port
module A1 {
module B2 {
def x3 = 1
}
}
module B4 {
module A5 {
def y6 = 2
}
}
module C7 {
import A8
import B9
def z10 = x11
+ y12
}
Fig. 12. Anoma-
lous resolution
R
4 7 !
at A4
body
of A4
sical.
culus
ments
les to
mport
(X)
(I)
us in
on is
rule)
rule); since the set R(G)
2
1
3
1
3
2

Resolution Algorithm
< P
P,
nstan-
R[I](xR
) := let (r, s) = EnvE [{xR
} [ I, ;](Sc(xR
))} in
(
U if r = P and {xD
|xD
2 s} = ;
{xD
|xD
2 s}
Envre [I, S](S) :=
(
(T, ;) if S 2 S or re = ?
Env
L[{D}
re [I, S](S)
EnvL
re [I, S](S) :=
[
l2Max(L)
⇣
Env
{l0
2L|l0
<l}
re [I, S](S) Envl
re [I, S](S)
⌘
EnvD
re [I, S](S) :=
(
(T, ;) if [] /2 re
(T, D(S))
Envl
re [I, S](S) :=
8
><
>:
(P, ;) if S
I
l contains a variable or ISl[I](S) = U
S
S02
⇣
ISl[I](S)[S
I
l
⌘
Env(l 1re)[I, {S} [ S](S0)
ISl
[I](S) :=
(
U if 9yR
2 (S
B
l I) s.t. R[I](yR
) = U
{S0 | yR
2 (S
B
l I) ^ yD
2 R[I](yR
) ^ yD
S0}

Language-independent 𝜶-equivalence
Program similarity
Equivalence
define ↵-equivalence using scope graphs. Except for the leaves rep
ifiers, two ↵-equivalent programs must have the same abstract
write P ' P’ (pronounced “P and P’ are similar”) when the AS
re equal up to identifiers. To compare two programs we first c
T structures; if these are equal then we compare how identifiers
programs. Since two potentially ↵-equivalent programs are simi
s occur at the same positions. In order to compare the identifiers’
efine equivalence classes of positions of identifiers in a program: p
me equivalence class are declarations of or reference to the same
ract position ¯x identifies the equivalence class corresponding to
x.
n a program P, we write P for the set of positions correspon
s and declarations and PX for P extended with the artificial p
We define the
P
⇠ equivalence relation between elements of PX
if have same AST ignoring identifier names

Position equivalence
e same equivalence class are declarations of or reference to the same enti
abstract position ¯x identifies the equivalence class corresponding to the fr
ble x.
Given a program P, we write P for the set of positions corresponding
ences and declarations and PX for P extended with the artificial positio
¯x). We define the
P
⇠ equivalence relation between elements of PX as t
xive symmetric and transitive closure of the resolution relation.
nition 7 (Position equivalence).
` p : r i
x 7 ! di0
x
i
P
⇠ i0
i0 P
⇠ i
i
P
⇠ i0
i
P
⇠ i0
i0 P
⇠ i00
i
P
⇠ i00
i
P
⇠ i
his equivalence relation, the class containing the abstract free variable d
ion can not contain any other declaration. So the references in a particu
are either all free or all bound.
mma 6 (Free variable class). The equivalence class of a free variable do
contain any other declaration, i.e. 8 di
x s.t. i
P
⇠ ¯x =) i = ¯x
xi xi'
Program similarity
Equivalence
x.
We define the
P

Position equivalence
e same equivalence class are declarations of or reference to the same enti
abstract position ¯x identifies the equivalence class corresponding to the fr
ble x.
Given a program P, we write P for the set of positions corresponding
ences and declarations and PX for P extended with the artificial positio
¯x). We define the
P
⇠ equivalence relation between elements of PX as t
xive symmetric and transitive closure of the resolution relation.
nition 7 (Position equivalence).
` p : r i
x 7 ! di0
x
i
P
⇠ i0
i0 P
⇠ i
i
P
⇠ i0
i
P
⇠ i0
i0 P
⇠ i00
i
P
⇠ i00
i
P
⇠ i
his equivalence relation, the class containing the abstract free variable d
ion can not contain any other declaration. So the references in a particu
are either all free or all bound.
mma 6 (Free variable class). The equivalence class of a free variable do
contain any other declaration, i.e. 8 di
x s.t. i
P
⇠ ¯x =) i = ¯x
xi xi'
Program similarity
Equivalence
x.
We define the
P
ed proof is in appendix A.5, we first prove:
r i
x 7 ! d ¯x
x ) =) 8 p di0
x , p ` r i
x 7 ! di0
x =) i0
= ¯x ^ p =
eed by induction on the equivalence relation.
ce classes defined by this relation contain references to
me entity. Given this relation, we can state that two p
f the identifiers at identical positions refer to the same e
he same equivalence class:
(↵-equivalence). Two programs P1 and P2 are ↵-equi
2) when they are similar and have the same ⇠-equivalen
P1
↵
⇡ P2 , P1 ' P2 ^ 8 e e0
, e
P1
⇠ e0
, e
P2
⇠ e0
is an equivalence relation since ' and , are equivalenc(with some further details about free variables)
Alpha equivalence

Preserving ambiguity
25
module A1 {
def x2 := 1
}
module B3 {
def x4 := 2
}
module C5 {
import A6 B7 ;
def y8 := x9
}
module D10 {
import A11 ;
def y12 := x13
}
module E14 {
import B15 ;
def y16 := x17
}
P1
module AA1 {
def z2 := 1
}
module BB3 {
def z4 := 2
}
module C5 {
import AA6 BB7 ;
def s8 := z9
}
module D10 {
import AA11 ;
def u12 := z13
}
module E14 {
import BB15 ;
def v16 := z17
}
P2
module A1 {
def z2 := 1
}
module B3 {
def x4 := 2
}
module C5 {
import A6 B7 ;
def y8 := z9
}
module D10 {
import A11 ;
def y12 := z13
}
module E14 {
import B15 ;
def y16 := x17
}
P3
Fig. 23. ↵-equivalence and duplicate declarationP1
Lemma 6 (Free variable class). The equivalence class of a fr
ot contain any other declaration, i.e. 8 di
x s.t. i
P
⇠ ¯x =) i = ¯x
Proof. Detailed proof is in appendix A.5, we first prove:
8 r i
x, (` > : r i
x 7 ! d ¯x
x ) =) 8 p di0
x , p ` r i
x 7 ! di0
x =) i0
= ¯x
nd then proceed by induction on the equivalence relation.
The equivalence classes defined by this relation contain reference
ions of the same entity. Given this relation, we can state that t
↵-equivalent if the identifiers at identical positions refer to the s
s belong to the same equivalence class:
Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵
oted P1
↵
⇡ P2) when they are similar and have the same ⇠-equi
P1
↵
⇡ P2 , P1 ' P2 ^ 8 e e0
, e
P1
⇠ e0
, e
P2
⇠ e0P2 P2
Lemma 6 (Free variable class). The e
not contain any other declaration, i.e. 8 d
Proof. Detailed proof is in appendix A.5,
8 r i
x, (` > : r i
x 7 ! d ¯x
x ) =) 8 p di0
x , p `
and then proceed by induction on the equ
The equivalence classes defined by this rel
tions of the same entity. Given this relatio
↵-equivalent if the identifiers at identical
is belong to the same equivalence class:
Definition 8 (↵-equivalence). Two pro
noted P1
↵
⇡ P2) when they are similar and
P1
↵
⇡ P2 , P1 ' P2 ^ 8P3

Types from Declaration
def x : int = 6
def x : int = 6
def f = fun (y : int) { x + y }
Static type-checking (or inference) is one obvious client for name resolution
In many cases, we can perform resolution before doing type analysis

def x : int = 6
def x : int = 6

Type-Dependent Name Resolution
But sometimes we need types before we can do name resolution
record A1 { x1 : int }
record B1 { a1 : A2 ; x2 : bool}
def z1 : B2 = ...
def y1 = z2.x3
def y2 = z3.a2.x4

Type-Dependent Name Resolution
But sometimes we need types before we can do name resolution
record A1 { x1 : int }
record B1 { a1 : A2 ; x2 : bool}
def z1 : B2 = ...
def y1 = z2.x3
def y2 = z3.a2.x4
Our approach: interleave partial name resolution with type resolution
(also using constraints)
See PEPM 2016 paper / talk

Constraint Language
C := CG
| CTy | CRes | C ^ C | True
CG
:= R S | S D | S l
S | D S | S l
R
CRes := R 7! D | D S | !N | N ⇢
⇠ N
CTy := T ⌘ T | D : T
D := | xD
i
R := xR
i
S := & | n
T := ⌧ | c(T, ..., T) with c 2 CT
N := D(S) | R(S) | V(S)
Figure 7. Syntax of constraints
scope graph resolution calculus (described in Section 3.3). Finally,
we apply |= with G set to CG
.

LMR: Language with Modules and Records
prog = decl⇤
decl = module id {decl⇤
}
| import id
| def bind
| record id {fdecl⇤
}
fdecl = id : ty
ty = Int
| Bool
| id
| ty ! ty
exp = int
| true
| false
| id
| exp exp
| if exp then exp else exp
| fun ( id : ty ) {exp}
| exp exp
| letrec tbind in exp
| new id {fbind⇤
}
| with exp do exp
| exp . id
bind = id = exp
| tbind
tbind = id : ty = exp
fbind = id = exp
Figure 5. Syntax of LMR.
[[ds]]prog :=
[[module xi {ds}]]decl
s :=
[[import xi]]decl
s :=
[[def b]]decl
s :=
[[record xi {fs}]]decl
s :=
[[xi = e]]bind
s :=
[[xi : t = e]]bind
s :=
[[xi:t]]fdecl
sr,sd
:=
[[Int]]ty
s,t :=
[[Bool]]ty
s,t :=
[[t1 ! t2]]ty
s,t :=
[[xi]]ty
s,t :=
[[fun (xi:t1){e}]]exp
s,t :=

Constraints for Declarations
p
[[ds]]prog := !D(s) ^ [[ds]]decl⇤
s
[[module xi {ds}]]decl
s := s xD
i ^ xD
i s0 ^ s0 P
s ^ !D(s0) ^ [[ds]]decl⇤
s0
[[import xi]]decl
s := xR
i s ^ s I
xR
i
[[def b]]decl
s := [[b]]bind
s
[[record xi {fs}]]decl
s := s xD
i ^ xD
i s0 ^ s0 P
s ^ !D(s0) ^ [[fs]]fdecl⇤
s,s0
[[xi = e]]bind
s := s xD
i ^ xD
i : ⌧ ^ [[e]]exp
s,⌧
[[xi : t = e]]bind
s := s xD
i ^ xD
i : ⌧ ^ [[t]]ty
s,⌧ ^ [[e]]exp
s,⌧
[[xi:t]]fdecl
sr,sd
:= sd xD
i ^ xD
i : ⌧ ^ [[t]]ty
sr,⌧
[[Int]]ty
s,t := t ⌘ Int
[[Bool]]ty
s,t := t ⌘ Bool
[[t1 ! t2]]ty
s,t := t ⌘ Fun[⌧1,⌧2] ^ [[t1]]ty
s,⌧1 ^ [[t2]]ty
s,⌧2
[[xi]]ty
:= t ⌘ Rec( ) ^ xR
s ^ xR
7!

Constraints for Expressions
LMR.
be the algo-
R’s concrete
deﬁned by a
by syntactic
ach function
nt and possi-
parameters,
sibly involv-
ables or new
s are deﬁned
ach possible
gory. For ex-
rules, and is
e s in which
the expres-
ected type t
the notation
ms of syntac-
result of ap-
and return-
esulting con-
pty sequence.
1 2 s,t 1 2 1 s,⌧1 2 s,⌧2
[[xi]]ty
s,t := t ⌘ Rec( ) ^ xR
i s ^ xR
i 7!
[[fun (xi:t1){e}]]exp
s,t := t ⌘ Fun[⌧1,⌧2] ^ s0 P
s ^ !D(s0) ^ s0 xD
i
^ xD
i : ⌧1 ^ [[t1]]ty
s,⌧1 ^ [[e]]exp
s0,⌧2
[[letrec bs in e]]exp
s,t := s0 P
s ^ !D(s0) ^ [[bs]]bind
s0 ^ [[e]]exp
s0,t
[[n]]exp
s,t := t ⌘ Int
[[true]]exp
s,t := t ⌘ Bool
[[false]]exp
s,t := t ⌘ Bool
[[e1 e2]]exp
s,t := t ⌘ t3 ^ ⌧1 ⌘ t1 ^ ⌧2 ⌘ t2 ^ [[e1]]exp
s,⌧1 ^ [[e2]]exp
s,⌧2
(where has type t1 ⇥ t2 ! t3)
[[if e1 then e2 else e3]]exp
s,t := ⌧1 ⌘ Bool ^ [[e1]]exp
s,⌧1 ^ [[e2]]exp
s,t ^ [[e3]]exp
s,t
[[xi]]exp
s,t := xR
i s ^ xR
i 7! ^ : t
[[e1 e2]]exp
s,t := ⌧ ⌘ Fun[⌧1,t] ^ [[e1]]exp
s,⌧ ^ [[e2]]exp
s,⌧1
[[e.xi]]exp
s,t := [[e]]exp
s,⌧ ^ ⌧ ⌘ Rec( ) ^ & ^ s0 I
& ^ [[xi]]exp
s0,t
[[with e1 do e2]]exp
s,t := [[e1]]exp
s,⌧ ^ ⌧ ⌘ Rec( ) ^ &
^ s0 P
s ^ s0 I
& ^ [[e2]]exp
s0,t
[[new xi {bs}]]exp
s,t := xR
i s ^ xR
i 7! ^ s0 I
xR
i
^ [[bs]]fbind⇤
s,s0 ^ V(s0) ⇡ R(s0) ^ t ⌘ Rec( )
[[xi = e]]fbind
s,s0 := xR
i s0 ^ xR
i 7! ^ : ⌧ ^ [[e]]exp
s,⌧

Summary: A Theory of Name Resolution
• Representation: Scope Graphs
- Standardized representation for lexical scoping structure of programs
- Path in scope graph relates reference to declaration
• Formalism: Name Binding Constraints
- References + Declarations + Scopes + Reachability + Visibility
- Language-speciﬁc rules map AST to constraints
- Resolution calculus: correctness of path with respect to scope graph
- Name resolution algorithm
- Alpha equivalence
- Mapping from graph to tree (to text)
- Refactorings
- And many other applications

Validation
• We have modeled a large set of example binding patterns
- definition before use
- different let binding flavors
- recursive modules
- imports and includes
- qualified names
- class inheritance
- partial classes
• Next goal: fully model some real languages
- Java
- ML

Future Work
• Scope graph semantics for binding speciﬁcation languages
- starting with NaBL
- or rather: a redesign of NaBL based on scope graphs
• Resolution-sensitive program transformations
- renaming, refactoring, substitution, …
• Dynamic analogs to static scope graphs
- how does scope graph relate to memory at run-time?
• Supporting mechanized language meta-theory
- relating static and dynamic bindings

Name binding with scope graphs

More Related Content

What's hot (20)

Similar to Name binding with scope graphs (20)

More from Eelco Visser (20)

Recently uploaded (20)

Name binding with scope graphs