IN4303 2016-2017 Compiler Construction

Static Name Resolution static analysis

Eelco Visser

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 }

}

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 }

}

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 }

}

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 }

}

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 verification 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 definition: 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

Semantictransform translate

eval analyze refactor

type check

Syntacticcoloring

outline view completion

Language = Sentences and Trees

parse

format

different representations convenient for different purposes

SDF3 defines Trees and Sentences

parse(s) = t where format(t) == s (modulo layout)

Expr.Int = INTExpr.Add = <<Expr> + <Expr>>Expr.Mul = <<Expr> * <Expr>>

trees (structure)

parse (text to tree)

format (tree to text) + =>

Grammar Engineering in Spoofax

Ambiguity

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 filter

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 ResolutionPierre Néron, Andrew Tolmach, Eelco Visser, Guido Wachsmuth

ESOP 2015

Language = Set of Trees

Fun

AddArgDecl

VarRefId Int

“1”

VarDeclId

“x”

TXINT

“x”

Tree is a convenient interface for transforming programs

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 specification

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 - Basis for syntactic and semantic operations - Supports ambiguous / erroneous programs

• Formalism: Name Binding Specification- References + Declarations + Scopes + Reachability + Visibility - Language-specific rules: mapping constructs to scope graph

• Language-Independent Interpretation- 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, Qualified Names

• Visibility- Ambiguous resolutions - Disambiguation: path specificity, 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 + 1def x1 = 5

Simple Scopes

def y1 = x2 + 1def x1 = 5

Simple Scopes

def y1 = x2 + 1def x1 = 5

Simple Scopes

S0def y1 = x2 + 1def x1 = 5

Simple Scopes

Scope

S0def y1 = x2 + 1def x1 = 5

S0

S

Simple Scopes

Declaration

Scope

S0def y1 = x2 + 1def x1 = 5

y1

x1S0

Sx

Simple Scopes

Reference

Declaration

Scope

S0def y1 = x2 + 1def x1 = 5

y1

x1S0x2

Sx

x

Simple Scopes

Reference

Declaration

Scope

Reference Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

y1

x1S0x2

Sx

x

Simple Scopes

Reference

Declaration

Scope

Reference Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

R

y1

x1S0x2

Sx

x

Simple Scopes

Reference

Declaration

Scope

Reference Step Declaration Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

xS

xS D

R

y1

x1S0x2

Sx

x

Simple Scopes

Reference

Declaration

Scope

Reference Step Declaration Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

xS

xS D

R D

y1

x1S0x2

Sx

x

Lexical Scoping

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

Lexical Scoping

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

Lexical Scoping

S1

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

Lexical Scoping

S1

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

z1

x1S0z2

Lexical Scoping

S1

S0def 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

S’S

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 }

S1

y1y2 x2

z1

x1S0z2

R

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

SAmodule A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

Imports

S0

SB

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

SAmodule 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

RP

S R1 R2 SR

SRS I(R1)

Import Step

Imports

Associated scope

Import

S0

SB

SAmodule 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

RP

D

S R1 R2 SR

SRS I(R1)

Import Step

Imports

Associated scope

Import

S0

SB

SAmodule 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

RP

D

S R1 R2 SR

SRS I(R1)

Import Step

Imports

Associated scope

Import

S0

SB

SAmodule 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

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2 X1

s1

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2 X1

s1

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2

R D

X1

s1

Qualified 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

A Calculus for Name Resolution

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)

A Calculus for Name Resolution

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

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

z1 x2

x1S0x3

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

z1 x2

x1S0x3

RS0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

z1 x2

x1S0x3

R DS0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

z1 x2

x1S0x3

R

D

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

z1 x2

x1S0x3

R D

D

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Ambiguous Resolutions

match t with | A x | B x => …

z1 x2

x1S0x3

R D

D

S0 def 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

S1S2

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

Shadowing

S0

S1S2

S1

S2

x1

y1

y2 x2

z1

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

Shadowing

S0

S1S2

S1

S2

x1

y1

y2 x2

z1

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

Shadowing

S0

S1S2

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

S1S2

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

S1S2

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

S1S2

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

S1S2

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

Imports shadow Parents

A1

SA

z1

B1

SB

z2

S0

A2

x1

z3S0def z3 = 2

module A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

SA

SB

Imports shadow Parents

A1

SA

z1

B1

SB

z2

S0

A2

x1

z3S0def z3 = 2

module A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

SA

SB

Imports shadow Parents

A1

SA

z1

B1

SB

z2

S0

A2

x1

I(A2)R D

z3S0def z3 = 2

module A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

SA

SB

Imports shadow Parents

A1

SA

z1

B1

SB

z2

S0

A2

x1

I(A2)R D

P

Dz3

R

S0def z3 = 2

module A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

SA

SB

Imports shadow Parents

I(_).p’ < P.p

A1

SA

z1

B1

SB

z2

S0

A2

x1

I(A2)R D

P

Dz3

R

S0def z3 = 2

module A1 { def z1 = 5}module B1 { import A2 def x1 = 1 + z2}

SA

SB

Imports shadow Parents

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

Dz3

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 A2def x1 = 1 + z2

SA

Imports vs. Includes

S0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1z3

Imports vs. Includes

S0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1

R

z3 D

Imports vs. Includes

S0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

Imports vs. Includes

S0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

D < I(_).p’

Imports vs. Includes

S0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

D < I(_).p’ ⇒ R.D < R.I(A2).D

Imports vs. Includes

A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

D < I(_).p’ ⇒ R.D < R.I(A2).D

S0def z3 = 2

module A1 { def z1 = 5}

include A2def x1 = 1 + z2

SA

Imports vs. Includes

A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

D < I(_).p’ ⇒ R.D < R.I(A2).D

S0def z3 = 2

module A1 { def z1 = 5}

include A2def x1 = 1 + z2

SA

X

Imports vs. Includes

A1

SA

z1

z2

S0

A2

x1

I(A2)

R

D

z3R

D

D < I(_).p’

S0def z3 = 2

module A1 { def z1 = 5}

include A2def x1 = 1 + z2

SA

X

Import Parents

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

N1

SN

s2

S0

N2 X1

s1

Import Parents

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

N1

SN

s2

S0

N2 X1

s1

R

I(N2)

D

P

Import Parents

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

N1

SN

s2

S0

N2 X1

s1

R

I(N2)

D

P

Import Parents

def s1 = 5module 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

Transitive vs. Non-Transitive

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

SA

SB

SC

Transitive vs. Non-Transitive

??

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

SA

SB

SC

Transitive vs. Non-Transitive

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

Transitive vs. Non-Transitive

A1

SA

z1

B1

SB

S0

A2

I(A2)

D

C1

SCz2I(B2)

R

x1 B2

??

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

SA

SB

SC

Transitive vs. Non-Transitive

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

SCz2I(B2)

R

x1 B2

??

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

SA

SB

SC

A Calculus for Name Resolution

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

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 = 0def b2 = 1def c3 = 2

letpar a4 = c5 b6 = a7 c8 = b9in a10+b11+c12

1

b2a1 c3

a4

b6

c12a10 b11

c5

b9

a7

c8

2

def a1 = 0def b2 = 1def c3 = 2

letrec a4 = c5 b6 = a7 c8 = b9in a10+b11+c12

1

b2a1 c3

a4

b6

c12a10 b11

c5

b9

a7

c8

2

4

3

def a1 = 0def b2 = 1def c3 = 2

let a4 = c5 b6 = a7 c8 = b9in a10+b11+c12

Definition before Use / Use before Definition

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

b10b9

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

g10f12 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?)

Blocks in Java

class Foo { void foo() {

int x = 1;{ int y = 2;}x = y;

}}

What is the scope graph for this program?

Is the y declaration visible to the y reference?

Constraint Language

Constraint Generation

module constraint-gen

imports signatures/-

rules

[[ Constr(t1, ..., tn) ^ (s1, …, sn) ]] := C1, ..., Cn.

one rule per abstract syntax constructor

Name Binding Constraints

false // always failstrue // always succeeds C1, C2 // conjunction of constraints

[[ e ^ (s) ]] // generate constraints for sub-term

new s // generate a new scope NS{x} <- s // declaration of name x in namespace NS in scope sNS{x} -> s // reference of name x in namespace NS in scope s s -> s' // unlabeled scope edge from s to s's -L-> s' // scope edge from s to s' labeled L NS{x} |-> d // resolve reference x in namespace NS to declaration d

C | error $[something is wrong] // custom error messageC | warning $[does not look right] // custom warning

Tiger Name Binding

Let Bindings

let var x : int := 5 var f : int := 1in for y := 1 to x do ( f := f * y )end

let function fact(n : int) : int = if n < 1 then 1 else (n * fact(n - 1)) in fact(10)end

Let Bindings are Sequential

let var x : int := 0 + z // z not in scope var y : int := x + 1 var z : int := x + y + 1 in x + y + zend

Adjacent Function Declarations are Mutually Recursive

let function odd(x : int) : int = if x > 0 then even(x - 1) else false function even(x : int) : int = if x > 0 then odd(x - 1) else true in even(34) end

let function odd(x : int) : int = if x > 0 then even(x - 1) else false var x : int function even(x : int) : int = if x > 0 then odd(x - 1) else true in even(34) end

Namespaces

let type foo = int function foo(x : foo) : foo = 3 var foo : foo := foo(4) in foo(56) + foo // both refer to the variable fooend

Tiger in NaBL2

Set Up

module static-semantics

imports signatures/-imports nabl-lib

signature name resolution labels D, P, I well-formedness P* . I* order D < P, D < I, I < Prules

init ^ (s) := new s, // generate the root scope Type{"int"} <- s. // declare primitive type int

Library

module nabl-lib

rules // auxiliary

[[ None() ^ (s) ]] := true. [[ Some(e) ^ (s) ]] := [[ e ^ (s) ]].

Map[[ [] ^ (s) ]] := true. Map[[ [ x | xs ] ^ (s) ]] := [[ x ^ (s) ]], Map[[ xs ^ (s) ]].

Map2[[ [] ^ (s, s') ]] := true. Map2[[ [ x | xs ] ^ (s, s') ]] := [[ x ^ (s, s') ]], Map2[[ xs ^ (s, s') ]].

Variable Declarations and References

rules // variable declarations

[[ VarDec(x, t, e) ^ (s, s_outer) ]] := Var{x} <- s, [[ t ^ (s_outer) ]], [[ e ^ (s_outer) ]]. [[ VarDecNoInit(x, t) ^ (s, s_outer) ]] := Var{x} <- s, [[ t ^ (s_outer) ]].

rules // variable references [[ Var(x) ^ (s) ]] := Var{x} -> s, // declare x as variable reference Var{x} |-> d. // check that x resolves to a declaration

let var x : int := 5 var f : int := 1in for y := 1 to x do ( f := f * y )end

For Binds Loop Index Variable

let var x : int := 5 var f : int := 1in for y := 1 to x do ( f := f * y )end

rules // binding statements

[[ For(Var(x), e1, e2, e3) ^ (s) ]] := new s', s' -P-> s, Var{x} <- s', [[ e1 ^ (s) ]], // x not bound in loop bounds [[ e2 ^ (s) ]], [[ e3 ^ (s') ]]. // x bound in body

Function Declarations and Referencesrules // function declarations [[ FunDecs(fdecs) ^ (s, s_outer) ]] := Map2[[ fdecs ^ (s, s_outer) ]]. [[ FunDec(f, args, t, e) ^ (s, s_outer) ]] := Var{f} <- s, // declare f new s', // declare a new scope for body of function s' -P-> s, // make lexical environment accessible in body Map2[[ args ^ (s', s_outer) ]], [[ t ^ (s_outer) ]], [[ e ^ (s') ]]. [[ FArg(x, t) ^ (s, s_outer) ]] := Var{x} <- s, // declare argument x as a variable declaration [[ t ^ (s_outer) ]].

rules // function calls [[ Call(Var(f), exps) ^ (s) ]] := Var{f} -> s, // declare f as a function reference Var{f} |-> d | error $[Function [f] not declared], // check that f resolves to a declaration Map[[ exps ^ (s) ]].

let function fact(n : int) : int = if n < 1 then 1 else (n * fact(n - 1)) in fact(10)end

Let Bindings are Sequential

rules // declarations

[[ Let(blocks, exps) ^ (s) ]] := new s', // declare a new scope for the names introduced by the let s' -P-> s, // declare s as its parent scope new s_body, // scope for body of the let Decs[[ blocks ^ (s', s_body) ]], Map[[ exps ^ (s_body) ]]. Decs[[ [] ^ (s, s_body) ]] := s_body -P-> s. Decs[[ [block | blocks] ^ (s_outer, s_body) ]] := new s', s' -P-> s_outer, [[ block ^ (s', s_outer) ]], Decs[[ blocks ^ (s', s_body) ]].

let var x : int := 0 + z // z not in scope var y : int := x + 1 var z : int := x + y + 1 in x + y + zend

Adjacent Function Declarations are Mutually Recursive

let function odd(x : int) : int = if x > 0 then even(x - 1) else false function even(x : int) : int = if x > 0 then odd(x - 1) else true in even(34) end

let function odd(x : int) : int = if x > 0 then even(x - 1) else false var x : int function even(x : int) : int = if x > 0 then odd(x - 1) else true in even(34) end

Namespaces

let type foo = int function foo(x : foo) : foo = 3 var foo : foo := foo(4) in foo(56) + foo // both refer to the variable fooend

rules // type declarations [[ TypeDecs(tdecs) ^ (s, s_outer) ]] := Map2[[ tdecs ^ (s, s_outer) ]]. [[ TypeDec(x, t) ^ (s, s_outer) ]] := Type{x} <- s, [[ t ^ (s_outer) ]].

rules // types

[[ Tid(x) ^ (s) ]] := Type{x} -> s, Type{x} |-> d | error $[Type [x] not declared].

Full Definition Online

https://github.com/MetaBorgCube/metaborg-tiger

https://github.com/MetaBorgCube/metaborg-tiger/blob/master/org.metaborg.lang.tiger/trans/static-semantics/static-semantics.nabl2

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

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 : TD := � | xD

i

R := x

Ri

S := & | nT := ⌧ | 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 simplyapply a multi-sorted substitution �, mapping type variables ⌧ toground types, declaration variables � to ground declarations andscope variables & to ground scopes. Thus, our overall definition ofsatisfaction for a program p is:

�(CG

p

), |= �(CResp

) ^ �(CTyp

) (⇧)

where �(E) denotes the application of the substitution � to all thevariables appearing in E that are in the domain of �. When theproposition ⇧ holds we say that and � resolve p.

Resolution and Typing Constraints The |= relation is given bythe inductive rules in Fig. 8, where = is the syntactic equality onterms and `G x

Ri

7�! x

Dj

is the resolution relation for graph G.The interpretation of a name collection JNKG is the multiset definedas follows: JD(S)KG = ⇡(DG(S)), JR(S)KG = ⇡(RG(S)), andJV(S)KG = ⇡({xD

i

| 9p, `G p : S 7�! x

Di

}) where ⇡(A) isthe multiset produced by projecting the identifiers from a set A ofreferences or declarations. Given a multiset M , 1

M

(x) denotes themultiplicity of x in M .

3.3 Resolution Calculus

The resolution calculus defines the resolution of a reference to adeclaration in a scope graph as a most specific, well-formed pathfrom reference to declaration through a sequence of edges. A pathp is a list of steps representing the atomic scope transitions in thegraph. There are three kinds of steps:• A (direct) edge step E(l, S2) is a direct transition from the

current scope to the scope S2. This step records the label ofthe scope transition that is used.

• A nominal edge step N(l, yR, S) requires the resolution of ref-

erence y

R to a declaration with associated scope S to allow atransition between the current scope and scope S.

• A complete path always ends with a declaration step D(xD) thatstores the declaration the path is leading to.

A path p is a valid resolution in the graph from reference x

Ri

to declaration x

Di

such that `G p : x

Ri

7�! x

Di

according tothe calculus rules in Fig. 9. These rules all implicitly apply toa fixed graph G, which we omit to avoid clutter. The calculusdefines the resolution relation in terms of edges in the scope graph,reachable declarations, and visible declarations. Here I is the set ofseen imports, a technical device needed to avoid “out of thin air”anomalies in resolution of nominal imports. We often drop I froma resolution when it is empty. The S component that appears inthe transitive closure rules is the set of seen scopes that is used toprevent cycles in the resolution path of a given reference.

G, |= True

(C-TRUE)

G, |= C1 G, |= C2

G, |= C1 ^ C2(C-AND)

(d) = T

G, |= d : T(C-TYPEOF)

`G p : xRi

7! x

Dj

G, |= x

Ri

7! x

Dj

(C-RESOLVE)

d GS

G, |= d S

(C-SCOPEOF)

8x,1JNKG (x) 1

G, |= !N(C-UNIQUE)

JN1KG ✓ JN2KGG, |= N1 ⇢⇠ N2

(C-SUBNAME)

t1 = t2

G, |= t1 ⌘ t2(C-EQ)

Figure 8. Interpretation of resolution and typing constraints

Resolution paths

s := D(xDi

) | E(l, S) | N(l, xRi

, S)

p := [] | s | p · p (inductively generated)[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)Well-formed paths

WF(p) , labels(p) 2 EVisibility ordering on paths

label(s1) < label(s2)s1 · p1 < s2 · p2

p1 < p2

s · p1 < s · p2Edges in scope graph

S1l

S2

I ` E(l, S2) : S1 �! S2(E)

S1l

y

Ri

y

Ri

/2 I I ` p : yRi

7�! y

Dj

y

Dj

S2

I ` N(l, yRi

, 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⇣ S

0 WF(p) S

0x

Di

I ` p · D(xDi

) : S⇢ x

Di

(R)

Visible declarations

I ` p : S⇢ x

Di

8j, p0(I ` p

0 : S⇢ x

Dj

) ¬(p0 < p))

I ` p : S 7�! x

Di

(V )

Reference resolution

x

Ri

S {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Figure 9. Resolution calculus from [14] extended for arbitraryedge labels and parameterized with well-formedness predicate WFand visibility ordering <. Here label projects the label from a stepand labels projects the sequence of labels from a path.

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 : TD := � | xD

i

R := x

Ri

S := & | nT := ⌧ | 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 simplyapply a multi-sorted substitution �, mapping type variables ⌧ toground types, declaration variables � to ground declarations andscope variables & to ground scopes. Thus, our overall definition ofsatisfaction for a program p is:

�(CG

p

), |= �(CResp

) ^ �(CTyp

) (⇧)

where �(E) denotes the application of the substitution � to all thevariables appearing in E that are in the domain of �. When theproposition ⇧ holds we say that and � resolve p.

Resolution and Typing Constraints The |= relation is given bythe inductive rules in Fig. 8, where = is the syntactic equality onterms and `G x

Ri

7�! x

Dj

is the resolution relation for graph G.The interpretation of a name collection JNKG is the multiset definedas follows: JD(S)KG = ⇡(DG(S)), JR(S)KG = ⇡(RG(S)), andJV(S)KG = ⇡({xD

i

| 9p, `G p : S 7�! x

Di

}) where ⇡(A) isthe multiset produced by projecting the identifiers from a set A ofreferences or declarations. Given a multiset M , 1

M

(x) denotes themultiplicity of x in M .

3.3 Resolution Calculus

The resolution calculus defines the resolution of a reference to adeclaration in a scope graph as a most specific, well-formed pathfrom reference to declaration through a sequence of edges. A pathp is a list of steps representing the atomic scope transitions in thegraph. There are three kinds of steps:• A (direct) edge step E(l, S2) is a direct transition from the

current scope to the scope S2. This step records the label ofthe scope transition that is used.

• A nominal edge step N(l, yR, S) requires the resolution of ref-

erence y

R to a declaration with associated scope S to allow atransition between the current scope and scope S.

• A complete path always ends with a declaration step D(xD) thatstores the declaration the path is leading to.

A path p is a valid resolution in the graph from reference x

Ri

to declaration x

Di

such that `G p : x

Ri

7�! x

Di

according tothe calculus rules in Fig. 9. These rules all implicitly apply toa fixed graph G, which we omit to avoid clutter. The calculusdefines the resolution relation in terms of edges in the scope graph,reachable declarations, and visible declarations. Here I is the set ofseen imports, a technical device needed to avoid “out of thin air”anomalies in resolution of nominal imports. We often drop I froma resolution when it is empty. The S component that appears inthe transitive closure rules is the set of seen scopes that is used toprevent cycles in the resolution path of a given reference.

G, |= True

(C-TRUE)

G, |= C1 G, |= C2

G, |= C1 ^ C2(C-AND)

(d) = T

G, |= d : T(C-TYPEOF)

`G p : xRi

7! x

Dj

G, |= x

Ri

7! x

Dj

(C-RESOLVE)

d GS

G, |= d S

(C-SCOPEOF)

8x,1JNKG (x) 1

G, |= !N(C-UNIQUE)

JN1KG ✓ JN2KGG, |= N1 ⇢⇠ N2

(C-SUBNAME)

t1 = t2

G, |= t1 ⌘ t2(C-EQ)

Figure 8. Interpretation of resolution and typing constraints

Resolution paths

s := D(xDi

) | E(l, S) | N(l, xRi

, S)

p := [] | s | p · p (inductively generated)[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)Well-formed paths

WF(p) , labels(p) 2 EVisibility ordering on paths

label(s1) < label(s2)s1 · p1 < s2 · p2

p1 < p2

s · p1 < s · p2Edges in scope graph

S1l

S2

I ` E(l, S2) : S1 �! S2(E)

S1l

y

Ri

y

Ri

/2 I I ` p : yRi

7�! y

Dj

y

Dj

S2

I ` N(l, yRi

, 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⇣ S

0 WF(p) S

0x

Di

I ` p · D(xDi

) : S⇢ x

Di

(R)

Visible declarations

I ` p : S⇢ x

Di

8j, p0(I ` p

0 : S⇢ x

Dj

) ¬(p0 < p))

I ` p : S 7�! x

Di

(V )

Reference resolution

x

Ri

S {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Figure 9. Resolution calculus from [14] extended for arbitraryedge labels and parameterized with well-formedness predicate WFand visibility ordering <. Here label projects the label from a stepand labels projects the sequence of labels from a path.

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 : TD := � | xD

i

R := x

Ri

S := & | nT := ⌧ | 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 simplyapply a multi-sorted substitution �, mapping type variables ⌧ toground types, declaration variables � to ground declarations andscope variables & to ground scopes. Thus, our overall definition ofsatisfaction for a program p is:

�(CG

p

), |= �(CResp

) ^ �(CTyp

) (⇧)

where �(E) denotes the application of the substitution � to all thevariables appearing in E that are in the domain of �. When theproposition ⇧ holds we say that and � resolve p.

Resolution and Typing Constraints The |= relation is given bythe inductive rules in Fig. 8, where = is the syntactic equality onterms and `G x

Ri

7�! x

Dj

is the resolution relation for graph G.The interpretation of a name collection JNKG is the multiset definedas follows: JD(S)KG = ⇡(DG(S)), JR(S)KG = ⇡(RG(S)), andJV(S)KG = ⇡({xD

i

| 9p, `G p : S 7�! x

Di

}) where ⇡(A) isthe multiset produced by projecting the identifiers from a set A ofreferences or declarations. Given a multiset M , 1

M

(x) denotes themultiplicity of x in M .

3.3 Resolution Calculus

The resolution calculus defines the resolution of a reference to adeclaration in a scope graph as a most specific, well-formed pathfrom reference to declaration through a sequence of edges. A pathp is a list of steps representing the atomic scope transitions in thegraph. There are three kinds of steps:• A (direct) edge step E(l, S2) is a direct transition from the

current scope to the scope S2. This step records the label ofthe scope transition that is used.

• A nominal edge step N(l, yR, S) requires the resolution of ref-

erence y

R to a declaration with associated scope S to allow atransition between the current scope and scope S.

• A complete path always ends with a declaration step D(xD) thatstores the declaration the path is leading to.

A path p is a valid resolution in the graph from reference x

Ri

to declaration x

Di

such that `G p : x

Ri

7�! x

Di

according tothe calculus rules in Fig. 9. These rules all implicitly apply toa fixed graph G, which we omit to avoid clutter. The calculusdefines the resolution relation in terms of edges in the scope graph,reachable declarations, and visible declarations. Here I is the set ofseen imports, a technical device needed to avoid “out of thin air”anomalies in resolution of nominal imports. We often drop I froma resolution when it is empty. The S component that appears inthe transitive closure rules is the set of seen scopes that is used toprevent cycles in the resolution path of a given reference.

G, |= True

(C-TRUE)

G, |= C1 G, |= C2

G, |= C1 ^ C2(C-AND)

(d) = T

G, |= d : T(C-TYPEOF)

`G p : xRi

7! x

Dj

G, |= x

Ri

7! x

Dj

(C-RESOLVE)

d GS

G, |= d S

(C-SCOPEOF)

8x,1JNKG (x) 1

G, |= !N(C-UNIQUE)

JN1KG ✓ JN2KGG, |= N1 ⇢⇠ N2

(C-SUBNAME)

t1 = t2

G, |= t1 ⌘ t2(C-EQ)

Figure 8. Interpretation of resolution and typing constraints

Resolution paths

s := D(xDi

) | E(l, S) | N(l, xRi

, S)

p := [] | s | p · p (inductively generated)[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)Well-formed paths

WF(p) , labels(p) 2 EVisibility ordering on paths

label(s1) < label(s2)s1 · p1 < s2 · p2

p1 < p2

s · p1 < s · p2Edges in scope graph

S1l

S2

I ` E(l, S2) : S1 �! S2(E)

S1l

y

Ri

y

Ri

/2 I I ` p : yRi

7�! y

Dj

y

Dj

S2

I ` N(l, yRi

, 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⇣ S

0 WF(p) S

0x

Di

I ` p · D(xDi

) : S⇢ x

Di

(R)

Visible declarations

I ` p : S⇢ x

Di

8j, p0(I ` p

0 : S⇢ x

Dj

) ¬(p0 < p))

I ` p : S 7�! x

Di

(V )

Reference resolution

x

Ri

S {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Figure 9. Resolution calculus from [14] extended for arbitraryedge labels and parameterized with well-formedness predicate WFand visibility ordering <. Here label projects the label from a stepand labels projects the sequence of labels from a path.

Visibility Policies

Lexical scopeL := {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 IncludesL := {P, Inc} E := P

⇤ · Inc

⇤D < P, Inc < P

Transitive includes and imports, and non-transitive importsL := {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

In order to model the name binding features and resolution poli-cies from different programming languages, the scope graph andresolution calculus are parameterized with a set of labels L, a reg-ular expression E that defines the scope reachability policy, and anorder < on the L (extended with the built-in D label) that definesthe scope visibility policy. Fig. 9 defines generic predicates derivedfrom these parameters and used in the calculus. The regular expres-sion E entails a well-formedness predicate WF on paths obtainedby projecting the sequence of labels from the path and testing it formembership in the language of E . The ordering relation on labelsentails an ordering relation on paths using the lexicographic orderon the projected label sequences.

Fig. 10 presents several example instantiations for these param-eters, encoding different policies. The first policy defines lexicalscope in which scopes are transitively linked through parent edges(P) and local declarations shadow declarations in parents. The nextpolicy extends lexical scope with non-transitive imports (I). Thewell-formedness predicate allows an optional import at the end ofa lexical scope chain, ruling out access to the parents of an im-ported scope. Further, the policy states that imported declarationsshadow declarations in the lexical context. The transitive importspolicy extends this by allowing paths with a chain of imports (TI).The transitive includes policy is a variation in which local decla-rations do not shadow included (Inc) declarations. The final policycombines three import policies, not providing rules to disambiguatebetween paths through different kinds of import edges. Thus, a ref-erence that can be resolved through an import and an include edgeis ambiguous and can be flagged as an error.

4. Resolution Algorithm

In this section, we describe an algorithm for solving constraints inthe sense of Section 3.2, i.e. finding � and that satisfy (⇧). Ouralgorithm works only for a restricted class of generated constraints:all constraints in CG

p

must be ground, except that scope variables &can appear as targets in direct edge constraints (e.g. S l

&). Thisrestriction is met by the constraints generated by the LMR collec-tion algorithm in Section 2. Broader classes of constraints might beuseful for other languages; we defer exploration of algorithms thatcould handle these to future work.

4.1 Variables in Scope Graph Constraints

The basic approach of the algorithm is to interpret the scope graphconstraints as a scope graph G and then use it to resolve resolu-tion and typing constraints using a conventional unification-based

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 = ?EnvL[{D}

re

[I, S](S)

EnvLre

[I, S](S) :=[

l2Max(L)

⇣Env{l

02L|l0<l}re

[I, S](S)� Envlre

[I, S](S)⌘

EnvD

re

[I, S](S) :=((T, ;) if [] /2 re

(T, D(S))

Envlre

[I, S](S) :=

8><

>:

(P, ;) if SIl

contains a variable or ISl[I](S) = US

S

02⇣

ISl[I](S)[S

Il

⌘Env(l�1re)[I, {S} [ S](S0)

ISl[I](S) :=(U if 9yR 2 (S

Bl

\I) s.t. R[I](yR) = U

{S0 | yR2 (SBl

\I) ^ y

D2 R[I](yR) ^ y

DS

0}

Figure 11. Name Resolution Algorithm

algorithm. However, since scope graph constraints can contain vari-ables, we cannot fully define the scope graph before starting con-straint resolution, because we do not fully know �. Thus, our algo-rithm builds � (and ) incrementally. The key idea is that we cansolve some resolution and typing constraints even when � is notyet fully defined, in such a way that the solution remains valid as itbecomes more defined.

4.2 Name Resolution Algorithm

In order to solve resolution constraints (e.g. xR 7! �) or to com-pute the set of visible elements from a scope (V(S)) we need analgorithm that computes the name resolution relation (xR

i

7�! x

Dj

)specified by the calculus presented in Section 3.3. We introducedsuch an algorithm in our prior work [14], but it was specific to aparticular set of labels, visibility order, and well-formedness predi-cate. In this section, we present a generic version of the algorithmthat is parameterized by L, E and < as described in Section 3.4.

Incomplete Scope Graphs A further new requirement on thealgorithm is that it can operate on an incomplete scope graph,specified by a set of constraints that may still contains variablesas the targets of direct edges. The non-strictly positive premiseof the (V) rule of the resolution calculus makes the derivation ofa resolution relation from a graph non-monotonic with respect toadditions to the graph. For example, suppose that in some graphG a reference x

R in a scope S resolves to declaration x

Di

in theparent scope S

0. In a bigger graph G0 that also has a declarationx

Di

0 in S itself, xR will resolve to x

Di

0 , and the old resolution to x

Di

will be shadowed. Thus we cannot simply restrict resolution to thecomplete part of the graph, and expect the results to remain validas the graph becomes more completely known. Instead, we modifythe original algorithm to signal when a result is preliminary.

The Algorithm Fig. 11 defines a resolution algorithm that workson such incomplete scope graphs.The function for resolving a sin-gle reference, R[I](xR), returns either a set of declarations or U(unknown) if the reference cannot be resolved in the current graph.Similarly, the environment functions Env _

re

[I, S](S) return a pairconsisting of:

• a result flag, T (total) if all declarations visible from S canbe computed or P (partial) if there are still possible additionalresolutions (some scope variables are accessible)

Seen Imports

13

A

D2 :SA2 2 D(S

A1)

A

R4 2 I(S

root

)

A

R4 2 R(S

root

) A

D1 :SA1 2 D(S

root

)

A

R4 7�! A

D1 :SA1

S

root

�! S

A1 (⇤)S

root

⇢ A

D2 :SA2

A

R4 2 R(S

root

) S

root

7�! A

D2 :SA2

A

R4 7�! A

D2 :SA2

Fig. 10. Derivation for A

R4 7�! A

D2 :SA2 in a calculus without import tracking.

The complete definition of well-formed paths and specificity order on paths isgiven in Fig. 2. In Section 2.5 we discuss how alternative visibility policies canbe defined by just changing the well-formedness predicate and specificity order.

module A1 {

module A2 {

def a3 = ...

}

}

import A4

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

Seen imports. Consider the example in Fig. 11. Is declarationa3 reachable in the scope of reference a6? This reduces to thequestion whether the import of A4 can resolve to moduleA2. Surprisingly, it can, in the calculus as discussed so far,as shown by the derivation in Fig. 10 (which takes a fewshortcuts). The conclusion of the derivation is that A

R4 7�!

A

D2 :SA2 . This conclusion is obtained by using the import at A4

to conclude at step (*) that Sroot

�! S

A1 , i.e. that the bodyof module A1 is reachable! In other words, the import of A4is used in its own resolution. Intuitively, this is nonsensical.

To rule out this kind of behavior we extend the calculusto keep track of the set of seen imports I using judgementsof the form I ` p : xR

i

7�! x

Dj

. We need to extend all rules topass the set I, but only the rules for resolution and importare truly affected:

x

Ri

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

y

Ri

2 I(S1) \ I I ` p : yRi

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

With this final ingredient, we reach the full calculus inFig. 3. It is not hard to see that the resolution relation iswell-founded. The only recursive invocation (via the I rule)uses a strictly larger set I of seen imports (via the X rule); since the set R(G)is finite, I cannot grow indefinitely.

Anomalies. Although the calculus produces the desired resolutions for a widevariety of real language constructs, its behavior can be surprising on corner cases.Even with the “seen imports” mechanism, it is still possible for a single derivation

?

13

A

D2 :SA2 2 D(S

A1)

A

R4 2 I(S

root

)

A

R4 2 R(S

root

) A

D1 :SA1 2 D(S

root

)

A

R4 7�! A

D1 :SA1

S

root

�! S

A1 (⇤)S

root

⇢ A

D2 :SA2

A

R4 2 R(S

root

) S

root

7�! A

D2 :SA2

A

R4 7�! A

D2 :SA2

Fig. 10. Derivation for A

R4 7�! A

D2 :SA2 in a calculus without import tracking.

The complete definition of well-formed paths and specificity order on paths isgiven in Fig. 2. In Section 2.5 we discuss how alternative visibility policies canbe defined by just changing the well-formedness predicate and specificity order.

module A1 {

module A2 {

def a3 = ...

}

}

import A4

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

Seen imports. Consider the example in Fig. 11. Is declarationa3 reachable in the scope of reference a6? This reduces to thequestion whether the import of A4 can resolve to moduleA2. Surprisingly, it can, in the calculus as discussed so far,as shown by the derivation in Fig. 10 (which takes a fewshortcuts). The conclusion of the derivation is that A

R4 7�!

A

D2 :SA2 . This conclusion is obtained by using the import at A4

to conclude at step (*) that Sroot

�! S

A1 , i.e. that the bodyof module A1 is reachable! In other words, the import of A4is used in its own resolution. Intuitively, this is nonsensical.

To rule out this kind of behavior we extend the calculusto keep track of the set of seen imports I using judgementsof the form I ` p : xR

i

7�! x

Dj

. We need to extend all rules topass the set I, but only the rules for resolution and importare truly affected:

x

Ri

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

y

Ri

2 I(S1) \ I I ` p : yRi

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

With this final ingredient, we reach the full calculus inFig. 3. It is not hard to see that the resolution relation iswell-founded. The only recursive invocation (via the I rule)uses a strictly larger set I of seen imports (via the X rule); since the set R(G)is finite, I cannot grow indefinitely.

Anomalies. Although the calculus produces the desired resolutions for a widevariety of real language constructs, its behavior can be surprising on corner cases.Even with the “seen imports” mechanism, it is still possible for a single derivation

13

A

D2 :SA2 2 D(S

A1)

A

R4 2 I(S

root

)

A

R4 2 R(S

root

) A

D1 :SA1 2 D(S

root

)

A

R4 7�! A

D1 :SA1

S

root

�! S

A1 (⇤)S

root

⇢ A

D2 :SA2

A

R4 2 R(S

root

) S

root

7�! A

D2 :SA2

A

R4 7�! A

D2 :SA2

Fig. 10. Derivation for A

R4 7�! A

D2 :SA2 in a calculus without import tracking.

The complete definition of well-formed paths and specificity order on paths isgiven in Fig. 2. In Section 2.5 we discuss how alternative visibility policies canbe defined by just changing the well-formedness predicate and specificity order.

module A1 {

module A2 {

def a3 = ...

}

}

import A4

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

Seen imports. Consider the example in Fig. 11. Is declarationa3 reachable in the scope of reference a6? This reduces to thequestion whether the import of A4 can resolve to moduleA2. Surprisingly, it can, in the calculus as discussed so far,as shown by the derivation in Fig. 10 (which takes a fewshortcuts). The conclusion of the derivation is that A

R4 7�!

A

D2 :SA2 . This conclusion is obtained by using the import at A4

to conclude at step (*) that Sroot

�! S

A1 , i.e. that the bodyof module A1 is reachable! In other words, the import of A4is used in its own resolution. Intuitively, this is nonsensical.

To rule out this kind of behavior we extend the calculusto keep track of the set of seen imports I using judgementsof the form I ` p : xR

i

7�! x

Dj

. We need to extend all rules topass the set I, but only the rules for resolution and importare truly affected:

x

Ri

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

y

Ri

2 I(S1) \ I I ` p : yRi

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

With this final ingredient, we reach the full calculus inFig. 3. It is not hard to see that the resolution relation iswell-founded. The only recursive invocation (via the I rule)uses a strictly larger set I of seen imports (via the X rule); since the set R(G)is finite, I cannot grow indefinitely.

Anomalies. Although the calculus produces the desired resolutions for a widevariety of real language constructs, its behavior can be surprising on corner cases.Even with the “seen imports” mechanism, it is still possible for a single derivation

13

A

D2 :SA2 2 D(S

A1)

A

R4 2 I(S

root

)

A

R4 2 R(S

root

) A

D1 :SA1 2 D(S

root

)

A

R4 7�! A

D1 :SA1

S

root

�! S

A1 (⇤)S

root

⇢ A

D2 :SA2

A

R4 2 R(S

root

) S

root

7�! A

D2 :SA2

A

R4 7�! A

D2 :SA2

Fig. 10. Derivation for A

R4 7�! A

D2 :SA2 in a calculus without import tracking.

The complete definition of well-formed paths and specificity order on paths isgiven in Fig. 2. In Section 2.5 we discuss how alternative visibility policies canbe defined by just changing the well-formedness predicate and specificity order.

module A1 {

module A2 {

def a3 = ...

}

}

import A4

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

Seen imports. Consider the example in Fig. 11. Is declarationa3 reachable in the scope of reference a6? This reduces to thequestion whether the import of A4 can resolve to moduleA2. Surprisingly, it can, in the calculus as discussed so far,as shown by the derivation in Fig. 10 (which takes a fewshortcuts). The conclusion of the derivation is that A

R4 7�!

A

D2 :SA2 . This conclusion is obtained by using the import at A4

to conclude at step (*) that Sroot

�! S

A1 , i.e. that the bodyof module A1 is reachable! In other words, the import of A4is used in its own resolution. Intuitively, this is nonsensical.

To rule out this kind of behavior we extend the calculusto keep track of the set of seen imports I using judgementsof the form I ` p : xR

i

7�! x

Dj

. We need to extend all rules topass the set I, but only the rules for resolution and importare truly affected:

x

Ri

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

y

Ri

2 I(S1) \ I I ` p : yRi

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

With this final ingredient, we reach the full calculus inFig. 3. It is not hard to see that the resolution relation iswell-founded. The only recursive invocation (via the I rule)uses a strictly larger set I of seen imports (via the X rule); since the set R(G)is finite, I cannot grow indefinitely.

Anomalies. Although the calculus produces the desired resolutions for a widevariety of real language constructs, its behavior can be surprising on corner cases.Even with the “seen imports” mechanism, it is still possible for a single derivation

Anomaly

13

A

D2 :SA2 2 D(S

A1)

A

R4 2 I(S

root

)

A

R4 2 R(S

root

) A

D1 :SA1 2 D(S

root

)

A

R4 7�! A

D1 :SA1

S

root

�! S

A1 (⇤)S

root

⇢ A

D2 :SA2

A

R4 2 R(S

root

) S

root

7�! A

D2 :SA2

A

R4 7�! A

D2 :SA2

Fig. 10. Derivation for A

R4 7�! A

D2 :SA2 in a calculus without import tracking.

The complete definition of well-formed paths and specificity order on paths isgiven in Fig. 2. In Section 2.5 we discuss how alternative visibility policies canbe defined by just changing the well-formedness predicate and specificity order.

module A1 {

module A2 {

def a3 = ...

}

}

import A4

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

Seen imports. Consider the example in Fig. 11. Is declarationa3 reachable in the scope of reference a6? This reduces to thequestion whether the import of A4 can resolve to moduleA2. Surprisingly, it can, in the calculus as discussed so far,as shown by the derivation in Fig. 10 (which takes a fewshortcuts). The conclusion of the derivation is that A

R4 7�!

A

D2 :SA2 . This conclusion is obtained by using the import at A4

to conclude at step (*) that Sroot

�! S

A1 , i.e. that the bodyof module A1 is reachable! In other words, the import of A4is used in its own resolution. Intuitively, this is nonsensical.

To rule out this kind of behavior we extend the calculusto keep track of the set of seen imports I using judgementsof the form I ` p : xR

i

7�! x

Dj

. We need to extend all rules topass the set I, but only the rules for resolution and importare truly affected:

x

Ri

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

y

Ri

2 I(S1) \ I I ` p : yRi

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

With this final ingredient, we reach the full calculus inFig. 3. It is not hard to see that the resolution relation iswell-founded. The only recursive invocation (via the I rule)uses a strictly larger set I of seen imports (via the X rule); since the set R(G)is finite, I cannot grow indefinitely.

Anomalies. Although the calculus produces the desired resolutions for a widevariety of real language constructs, its behavior can be surprising on corner cases.Even with the “seen imports” mechanism, it is still possible for a single derivation

21

3

1

3

2

Resolution Algorithm

Lexical scopeL := {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 IncludesL := {P, Inc} E := P

⇤ · Inc

⇤D < P, Inc < P

Transitive includes and imports, and non-transitive importsL := {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

In order to model the name binding features and resolution poli-cies from different programming languages, the scope graph andresolution calculus are parameterized with a set of labels L, a reg-ular expression E that defines the scope reachability policy, and anorder < on the L (extended with the built-in D label) that definesthe scope visibility policy. Fig. 9 defines generic predicates derivedfrom these parameters and used in the calculus. The regular expres-sion E entails a well-formedness predicate WF on paths obtainedby projecting the sequence of labels from the path and testing it formembership in the language of E . The ordering relation on labelsentails an ordering relation on paths using the lexicographic orderon the projected label sequences.

Fig. 10 presents several example instantiations for these param-eters, encoding different policies. The first policy defines lexicalscope in which scopes are transitively linked through parent edges(P) and local declarations shadow declarations in parents. The nextpolicy extends lexical scope with non-transitive imports (I). Thewell-formedness predicate allows an optional import at the end ofa lexical scope chain, ruling out access to the parents of an im-ported scope. Further, the policy states that imported declarationsshadow declarations in the lexical context. The transitive importspolicy extends this by allowing paths with a chain of imports (TI).The transitive includes policy is a variation in which local decla-rations do not shadow included (Inc) declarations. The final policycombines three import policies, not providing rules to disambiguatebetween paths through different kinds of import edges. Thus, a ref-erence that can be resolved through an import and an include edgeis ambiguous and can be flagged as an error.

4. Resolution Algorithm

In this section, we describe an algorithm for solving constraints inthe sense of Section 3.2, i.e. finding � and that satisfy (⇧). Ouralgorithm works only for a restricted class of generated constraints:all constraints in CG

p

must be ground, except that scope variables &can appear as targets in direct edge constraints (e.g. S l

&). Thisrestriction is met by the constraints generated by the LMR collec-tion algorithm in Section 2. Broader classes of constraints might beuseful for other languages; we defer exploration of algorithms thatcould handle these to future work.

4.1 Variables in Scope Graph Constraints

The basic approach of the algorithm is to interpret the scope graphconstraints as a scope graph G and then use it to resolve resolu-tion and typing constraints using a conventional unification-based

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 = ?EnvL[{D}

re

[I, S](S)

EnvLre

[I, S](S) :=[

l2Max(L)

⇣Env{l

02L|l0<l}re

[I, S](S)� Envlre

[I, S](S)⌘

EnvD

re

[I, S](S) :=((T, ;) if [] /2 re

(T, D(S))

Envlre

[I, S](S) :=

8><

>:

(P, ;) if SIl

contains a variable or ISl[I](S) = US

S

02⇣

ISl[I](S)[S

Il

⌘Env(l�1re)[I, {S} [ S](S0)

ISl[I](S) :=(U if 9yR 2 (S

Bl

\I) s.t. R[I](yR) = U

{S0 | yR2 (SBl

\I) ^ y

D2 R[I](yR) ^ y

DS

0}

Figure 11. Name Resolution Algorithm

algorithm. However, since scope graph constraints can contain vari-ables, we cannot fully define the scope graph before starting con-straint resolution, because we do not fully know �. Thus, our algo-rithm builds � (and ) incrementally. The key idea is that we cansolve some resolution and typing constraints even when � is notyet fully defined, in such a way that the solution remains valid as itbecomes more defined.

4.2 Name Resolution Algorithm

In order to solve resolution constraints (e.g. xR 7! �) or to com-pute the set of visible elements from a scope (V(S)) we need analgorithm that computes the name resolution relation (xR

i

7�! x

Dj

)specified by the calculus presented in Section 3.3. We introducedsuch an algorithm in our prior work [14], but it was specific to aparticular set of labels, visibility order, and well-formedness predi-cate. In this section, we present a generic version of the algorithmthat is parameterized by L, E and < as described in Section 3.4.

Incomplete Scope Graphs A further new requirement on thealgorithm is that it can operate on an incomplete scope graph,specified by a set of constraints that may still contains variablesas the targets of direct edges. The non-strictly positive premiseof the (V) rule of the resolution calculus makes the derivation ofa resolution relation from a graph non-monotonic with respect toadditions to the graph. For example, suppose that in some graphG a reference x

R in a scope S resolves to declaration x

Di

in theparent scope S

0. In a bigger graph G0 that also has a declarationx

Di

0 in S itself, xR will resolve to x

Di

0 , and the old resolution to x

Di

will be shadowed. Thus we cannot simply restrict resolution to thecomplete part of the graph, and expect the results to remain validas the graph becomes more completely known. Instead, we modifythe original algorithm to signal when a result is preliminary.

The Algorithm Fig. 11 defines a resolution algorithm that workson such incomplete scope graphs.The function for resolving a sin-gle reference, R[I](xR), returns either a set of declarations or U(unknown) if the reference cannot be resolved in the current graph.Similarly, the environment functions Env _

re

[I, S](S) return a pairconsisting of:

• a result flag, T (total) if all declarations visible from S canbe computed or P (partial) if there are still possible additionalresolutions (some scope variables are accessible)

Alpha Equivalence

Language-independent 𝜶-equivalence

Program similarity

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

if have same AST ignoring identifier names

Language-independent 𝜶-equivalence

Position equivalence

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

xi xi'

Program similarity

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

if have same AST ignoring identifier names

Language-independent 𝜶-equivalence

Position equivalence

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

xi xi'

Program similarity

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

if have same AST ignoring identifier names

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.(with some further details about free variables)

Alpha equivalence

Preserving ambiguity25

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 declaration

5.2 The

↵⇡ Relation

Free variables. The P⇠ equivalence classes corresponding to free variables x alsocontains the artificial position x̄. Since the equivalence classes of two equivalentprograms P1 and P2 have to be exactly the same, every element equivalent tox̄ (i.e. a free reference) in P1 is also equivalent to x̄ in P2. Therefore the freereferences of ↵-equivalent programs have to be identical.

Duplicate declarations. The definition allows us to also capture ↵-equivalenceof programs with duplicate declarations. For example, in the program P1 inFigure 20, x9 has a duplicate declaration (it can resolve to x2 through A1 or tox4 through B3) whereas x13 simply resolves to x2 and x17 to x4 . Thus positions2, 4, 9, 13, and 17 are in the same equivalence class. (Similarly, positions 1,6,and 11 form an equivalence class refering to module A and positions 3,7, and15 form an equivalence class refering to module B , while positions 8, 12, and 16each form singleton equivalence classes.) The program P2 is ↵-equivalent to P1:all members of each equivalence class have been consistently renamed. Howeverthe program P3, where only the first declaration of x and its direct referencesare renamed into z , is not ↵-equivalent to P1, z9 now only resolves to z2 thusthis program does not contain the initial ambiguity of P1.

5.3 Renaming

Renaming is the substitution of a bound variable by a new variable throughoutthe program. It has several practical applications such as rename refactoring inan IDE, transformation to program with unique identifiers, or as an intermediatetransformation when implementing capture-avoiding substitution.

P1

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

P2 P2

24

5.1 ↵-Equivalence

We now define ↵-equivalence using scope graphs. Except for the leaves represent-ing identifiers, two ↵-equivalent programs must have the same abstract syntaxtree. We write P ' P’ (pronounced “P and P’ are similar”) when the ASTs of Pand P’ are equal up to identifiers. To compare two programs we first comparetheir AST structures; if these are equal then we compare how identifiers behavein these programs. Since two potentially ↵-equivalent programs are similar, theidentifiers occur at the same positions. In order to compare the identifiers’ behav-ior, we define equivalence classes of positions of identifiers in a program: positionsin the same equivalence class are declarations of or reference to the same entity.The abstract position x̄ identifies the equivalence class corresponding to the freevariable x.

Given a program P, we write P for the set of positions corresponding toreferences and declarations and PX for P extended with the artificial positions(e.g. x̄). We define the P⇠ equivalence relation between elements of PX as thereflexive symmetric and transitive closure of the resolution relation.

Definition 7 (Position equivalence).

` p : r i

x

7�! d i

0

x

iP⇠ i0

i0P⇠ i

iP⇠ i0

iP⇠ i0 i0

P⇠ i00

iP⇠ i00 i

P⇠ i

In this equivalence relation, the class containing the abstract free variable dec-laration can not contain any other declaration. So the references in a particularclass are either all free or all bound.

Lemma 6 (Free variable class). The equivalence class of a free variable doesnot contain any other declaration, i.e. 8 d i

x

s.t. iP⇠ 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 d i

0

x

, p ` r i

x

7�! d i

0

x

=) i0 = x̄ ^ p = >and then proceed by induction on the equivalence relation.

The equivalence classes defined by this relation contain references to or declara-tions of the same entity. Given this relation, we can state that two program are↵-equivalent if the identifiers at identical positions refer to the same entity, thatis belong to the same equivalence class:

Definition 8 (↵-equivalence). Two programs P1 and P2 are ↵-equivalent (de-noted P1

↵⇡ P2) when they are similar and have the same ⇠-equivalence classes:

P1↵⇡ P2 , P1 ' P2 ^ 8 e e0, e

P1⇠ e0 , eP2⇠ e0

Remark 1.↵⇡ is an equivalence relation since ' and , are equivalence relations.

P3

Names and Types

Types from Declaration

def x : int = 6

def f = fun (y : int) { x + y }

def x : int = 6

def f = fun (y : int) { x + y }

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

Types from Declaration

def x : int = 6

def f = fun (y : int) { x + y }

def x : int = 6

def f = fun (y : int) { x + y }

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

Types from Declarationdef x : int = 6

def f = fun (y : int) { x + y }

def x : int = 6

def f = fun (y : int) { x + y }

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

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

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

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

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

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

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

More on types next week

Closing

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 - Basis for syntactic and semantic operations

• Formalism: Name Binding Constraints- References + Declarations + Scopes + Reachability + Visibility - Language-specific rules map AST to constraints

• Language-Independent Interpretation- 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 specification 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 Resolution

copyrights

86

Name Resolution 87

copyrights

Name Resolution

Pictures

Slide 1: Reference by Ian Charleton, some rights reserved

88