A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name...

196
A Theory of Name Resolution 1 2 Guido Wachsmuth Eelco Visser Pierre Neron Andrew Tolmach 1 1 1 2 [ESOP15]

Transcript of A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name...

Page 1: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name Resolution

1 2

Guido Wachsmuth

Eelco Visser

Pierre Neron

Andrew Tolmach

111 2

[ESOP15]

Page 2: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 3: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 4: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 5: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 6: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 7: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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 }

}

Page 8: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Use Scope Graphs toDescribe Name Resolution

Page 9: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Use Scope Graphs toDescribe Name Resolution ??

Page 10: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Page 11: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

Page 12: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

Page 13: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

Page 14: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

Page 15: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

… with rules encoded in many different ad-hoc ways Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

Page 16: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

… with rules encoded in many different ad-hoc ways Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

Page 17: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

… with rules encoded in many different ad-hoc ways Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

x:int, 𝚪

[3/x].𝛔

Page 18: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

… with rules encoded in many different ad-hoc ways Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

x:int, 𝚪 lookup(xi)

[3/x].𝛔

Page 19: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Name Resolution is Pervasive

Appears in many different artifacts…

… with rules encoded in many different ad-hoc ways Semantics

x : ⌧1,� ` e : ⌧2� ` �x.e : ⌧1 ! ⌧2

�(x) = ⌧

� ` x : ⌧

Compiler

Parsing Semantics Analysis

Code Genenation

SymbolTable

IDE

x:int, 𝚪 lookup(xi)

[3/x].𝛔

No standard approach, no re-use

Page 20: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Contrast with Syntax

Page 21: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Contrast with Syntax

A standardformalism

Context-Free

Grammars

Page 22: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Contrast with Syntax

A unique definition

A standardformalism

program = decl

decl = module id { decl

⇤}

| import qid

| def id = exp

exp = qid

| fun id { exp }

| fix id { exp }

| let bind

⇤in exp

| letrec bind

⇤in exp

| letpar bind

⇤in exp

| exp exp

| exp � exp

| int

qid = id

| id . qidbind = id = exp

Context-Free

Grammars

Page 23: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Contrast with Syntax

A unique definition

A standardformalism Supports

Parser

AST

Pretty-Printing

program = decl

decl = module id { decl

⇤}

| import qid

| def id = exp

exp = qid

| fun id { exp }

| fix id { exp }

| let bind

⇤in exp

| letrec bind

⇤in exp

| letpar bind

⇤in exp

| exp exp

| exp � exp

| int

qid = id

| id . qidbind = id = exp Highlighting

Context-Free

Grammars

Page 24: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Representing Bound Programs

Page 25: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Representing Bound Programs• Many approaches to representing the results of name

resolution within an (extended) AST, e.g. • numeric indexing [deBruijn72] • higher-order abstract syntax [PfenningElliott88] • nominal logic approaches [GabbayPitts02]

Page 26: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Representing Bound Programs• Many approaches to representing the results of name

resolution within an (extended) AST, e.g. • numeric indexing [deBruijn72] • higher-order abstract syntax [PfenningElliott88] • nominal logic approaches [GabbayPitts02]

• Good support for binding-sensitive AST manipulation

Page 27: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Representing Bound Programs• Many approaches to representing the results of name

resolution within an (extended) AST, e.g. • numeric indexing [deBruijn72] • higher-order abstract syntax [PfenningElliott88] • nominal logic approaches [GabbayPitts02]

• Good support for binding-sensitive AST manipulation

• But: Do not say how to resolve identifiers in the first place!

• Also: Can’t represent ill-bound programs

• And: Tend to be biased towards lambda-like bindings

Page 28: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding Specification Languages

Page 29: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding Specification Languages• Many proposals for domain-specific languages

(DSLs) for specifying binding structure of a (target) language, e.g. • Ott [Sewell+10] • Romeo [StansiferWand14] • Unbound [Weirich+11] • Cαml [Pottier06]

• NaBL [Konat+12]

Page 30: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding Specification Languages• Many proposals for domain-specific languages

(DSLs) for specifying binding structure of a (target) language, e.g. • Ott [Sewell+10] • Romeo [StansiferWand14] • Unbound [Weirich+11] • Cαml [Pottier06]

• NaBL [Konat+12]• Generate code to do resolution and record results

Page 31: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding Specification Languages• Many proposals for domain-specific languages

(DSLs) for specifying binding structure of a (target) language, e.g. • Ott [Sewell+10] • Romeo [StansiferWand14] • Unbound [Weirich+11] • Cαml [Pottier06]

• NaBL [Konat+12]• Generate code to do resolution and record results• But: what are the semantics of such a language?

Page 32: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

The Missing Piece

Page 33: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Answer: the meaning of a binding specification for language L should be given by a function from L programs to their “resolution structures”

The Missing Piece

Page 34: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Answer: the meaning of a binding specification for language L should be given by a function from L programs to their “resolution structures”

• So we need a (uniform, language-independent) method for describing such resolution structures...

The Missing Piece

Page 35: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Answer: the meaning of a binding specification for language L should be given by a function from L programs to their “resolution structures”

• So we need a (uniform, language-independent) method for describing such resolution structures...

• ...that can be used to compute the resolution of each program identifier

The Missing Piece

Page 36: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Answer: the meaning of a binding specification for language L should be given by a function from L programs to their “resolution structures”

• So we need a (uniform, language-independent) method for describing such resolution structures...

• ...that can be used to compute the resolution of each program identifier

• (or to verify that a claimed resolution is valid)

The Missing Piece

Page 37: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

Page 38: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

• Handle broad range of language binding features...

Page 39: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

• Handle broad range of language binding features...

• ...using minimal number of constructs

Page 40: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

• Handle broad range of language binding features...

• ...using minimal number of constructs

• Make resolution structure language-independent

Page 41: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

• Handle broad range of language binding features...

• ...using minimal number of constructs

• Make resolution structure language-independent

• Handle named collections of names (e.g. modules, classes, etc.) within the theory

Page 42: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Design Goals

• Handle broad range of language binding features...

• ...using minimal number of constructs

• Make resolution structure language-independent

• Handle named collections of names (e.g. modules, classes, etc.) within the theory

• Allow description of programs with resolution errors

Page 43: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name Resolution

Page 44: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name ResolutionFor statically lexically scoped languages

Page 45: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name Resolution

A standardformalism

Scope

Graphs

For statically lexically scoped languages

Page 46: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name Resolution

A unique representation

A standardformalism

Scope

Graphs

For statically lexically scoped languages

A1

SA

z1

B1

SB

S0

A2

I(A2)

D

C1

SCz2I(B2)

R

x1 B2

Page 47: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Theory of Name Resolution

A unique representation

A standardformalism

Scope

Graphs

Supports

Resolution

𝜶-equivalence

IDE Navigation

Refactoring tools

For statically lexically scoped languages

Reasoning tools

A1

SA

z1

B1

SB

S0

A2

I(A2)

D

C1

SCz2I(B2)

R

x1 B2

Page 48: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Scheme

Program Scope Graph

Resolved Program

Language-dependent

Language-independent*

Page 49: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Scheme

Program Scope Graph

Resolved Program

Language-dependent

Language-independent*

Resolution of a reference in a scope graph: Building a path from a reference node to a declaration node following path construction rules

Page 50: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Scheme

Program Scope Graph

Resolved Program

Language-dependent

Language-independent*

Resolution of a reference in a scope graph: Building a path from a reference node to a declaration node following path construction rules

*Parameterized by notions of path well-formedness and ordering

Page 51: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Scope Graphs by Example

Page 52: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Simple Scopes

def y1 = x2 + 1def x1 = 5

Page 53: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Simple Scopes

def y1 = x2 + 1def x1 = 5

Page 54: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Simple Scopes

def y1 = x2 + 1def x1 = 5

Page 55: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Simple Scopes

S0def y1 = x2 + 1def x1 = 5

Page 56: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Scope

Simple Scopes

S0def y1 = x2 + 1def x1 = 5

S0

S

Page 57: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Declaration

Scope

Simple Scopes

S0def y1 = x2 + 1def x1 = 5

y1

x1S0

Sx

Page 58: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Reference

Declaration

Scope

Simple Scopes

S0def y1 = x2 + 1def x1 = 5

y1

x1S0x2

Sx

x

Page 59: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Reference

Declaration

Scope

Simple Scopes

Reference Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

y1

x1S0x2

Sx

x

Page 60: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Reference

Declaration

Scope

Simple Scopes

Reference Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

R

y1

x1S0x2

Sx

x

Page 61: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Reference

Declaration

Scope

Simple Scopes

Reference Step Declaration Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

xS

xS D

R

y1

x1S0x2

Sx

x

Page 62: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Reference

Declaration

Scope

Simple Scopes

Reference Step Declaration Step

S0def y1 = x2 + 1def x1 = 5

Sx

Sx R

xS

xS D

R D

y1

x1S0x2

Sx

x

Page 63: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 64: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

z1 x2

x1S0x3

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 65: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

z1 x2

x1S0x3

RS0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 66: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

z1 x2

x1S0x3

R DS0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 67: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

z1 x2

x1S0x3

R

D

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 68: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Ambiguous Resolutions

z1 x2

x1S0x3

R D

D

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 69: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Ambiguous Resolutions

z1 x2

x1S0x3

R D

D

S0 def x1 = 5

def x2 = 3

def z1 = x3 + 1

Page 70: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Lexical Scoping

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

Page 71: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

Lexical Scoping

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

Page 72: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

Page 73: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

z1

x1S0z2

Page 74: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

S1

y1y2 x2

z1

x1S0z2

Page 75: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

S’S

Page 76: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

S’S

Page 77: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

S’S

Page 78: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

R

S’S

Page 79: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

R D

S’S

Page 80: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

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

S1

y1y2 x2

z1

x1S0z2

R

S’S

Page 81: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

Page 82: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

Page 83: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

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

Page 84: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S1

S0

Lexical Scoping

Parent

Well formed path: R.P*.D

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

Page 85: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 86: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

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

Page 87: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowing

S1

S2

x1

y1

y2 x2

z1

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

Page 88: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowing

S1

S2

x1

y1

y2 x2

z1

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

Page 89: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

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

S1

S2

x1

y1

y2 x2

z1

x3S0z2

R

P

P

D

Page 90: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowingdef 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

Page 91: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowing

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

Page 92: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowing

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

Page 93: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

S0

S1S2

Shadowing

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

Page 94: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports

S0

SB

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

Page 95: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 96: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Imports

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

Page 97: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 98: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 99: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 100: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 101: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 102: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 103: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 104: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 105: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 106: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Associated scope

Import

Imports

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

Page 107: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports shadow ParentsS0def z3 = 2

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

SA

SB

Page 108: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 109: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 110: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 111: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 112: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 113: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 114: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA

Page 115: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1z3

Page 116: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def z3 = 2

module A1 { def z1 = 5}

import A2def x1 = 1 + z2

SA A1

SA

z1

z2

S0

A2

x1

R

z3 D

Page 117: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def 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

Page 118: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def 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’

Page 119: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Imports vs. IncludesS0def 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

Page 120: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 121: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 122: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 123: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

Page 124: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

Page 125: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2 X1

s1

Page 126: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2 X1

s1

Page 127: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Qualified Names

module N1 { def s1 = 5}

module M1 { def x1 = 1 + N2.s2

}

S0

N1

SN

s2

S0

N2

R D

X1

s1

Page 128: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 129: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

Page 130: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

Page 131: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

N1

SN

s2

S0

N2 X1

s1

Page 132: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

N1

SN

s2

S0

N2 X1

s1

R

I(N2)

D

P

Page 133: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

N1

SN

s2

S0

N2 X1

s1

R

I(N2)

D

P

Page 134: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

def s1 = 5module N1 {

}

def x1 = 1 + N2.s2

S0

SN

Import Parents

Well formed path: R.P*.I(_)*.D

N1

SN

s2

S0

N2 X1

s1

R

I(N2)

D

P

Page 135: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

SA

SB

SC

Page 136: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

SA

SB

SC

Page 137: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Transitive vs. Non-Transitive

??

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

SA

SB

SC

Page 138: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 139: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 140: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 141: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Calculus for Name Resolution

S R1 R2 SR

SRS I(R1)

S’S

S’S P

Sx

Sx R

xS

xS D

Page 142: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Calculus for Name Resolution

S R1 R2 SR

SRS I(R1)

S’S

S’S P

Sx

Sx R

xS

xS D

Well formed path: R.P*.I(_)*.D

Page 143: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

A Calculus for Name Resolution

S R1 R2 SR

SRS I(R1)

S’S

S’S P

Sx

Sx R

xS

xS D

Reachability

Well formed path: R.P*.I(_)*.D

Page 144: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Well formed path: R.P*.I(_)*.D

Page 145: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 146: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Theory of Scope Graphs

Page 147: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Scope graphs, formally5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

declaration with name x at position i with optional associated scope S

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

reference with name x at position i

Page 148: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Scope graphs, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

declaration with name x at position i with optional associated scope S

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

reference with name x at position i

Page 149: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Scope graphs, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

declaration with name x at position i with optional associated scope S

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

reference with name x at position i

5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

Page 150: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution paths

Page 151: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution pathsxi xi'

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Page 152: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Visibility paths

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution pathsxi xi'

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Page 153: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

⋮Reachability paths

Visibility paths

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution pathsxi xi'

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Page 154: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

⋮Reachability paths

Visibility paths

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution pathsxi xi'

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

...may include import steps

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Page 155: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution calculus, formally

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

⋮Reachability paths

Visibility paths

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Resolution pathsxi xi'

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

...may include import steps

References and declarations

– x

Di

:S: declaration with name x atposition i and optional associatednamed scope S

– x

Ri

: reference with name x at posi-tion i

Scope graph

– G: scope graph– S(G): scopes S in G– D(S): declarations x

Di

:S0 in S

– R(S): references x

Ri

in S

– I(S): imports x

Ri

in S

– P(S): parent scope of S

Well-formedness properties

– P(S) is a partial function– The parent relation is well-founded– Each x

Ri

and x

Di

appears in exactlyone scope S

Fig. 1. Scope graphs

Resolution paths

s := D(xDi

) | I(xRi

, x

Dj

:S) | P

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

[] · p = p · [] = p

(p1 · p2) · p3 = p1 · (p2 · p3)

Well-formed paths

WF(p) , p 2 P

⇤ · I(_,_)⇤

Specificity ordering on paths

D(_) < I(_,_)(DI)

I(_,_) < P

(IP )

D(_) < P

(DP )

s1 < s2

s1 · p1 < s2 · p2(Lex1)

p1 < p2

s · p1 < s · p2(Lex2)

Fig. 2. Resolution paths, well-formednesspredicate, and specificity ordering.

Edges in scope graph

P(S1) = S2

I ` P : S1 �! S2(P )

y

Ri

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

7�! y

Dj

:S2

I ` I(yRi

, y

Dj

:S2) : S1 �! S2

(I)

Transitive closure

I ` [] : A ⇣ A

(N)

I ` s : A �! B I ` p : B ⇣ C

I ` s · p : A ⇣ C

(T )

Reachable declarations

x

Di

2 D(S0) I ` p : S ⇣ S

0 WF(p)I ` p · D(xD

i

) : 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

2 R(S) {xRi

} [ I ` p : S 7�! x

Dj

I ` p : xRi

7�! x

Dj

(X)

Fig. 3. Resolution calculus

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 5

Well-founded!

Page 156: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm

Page 157: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm

• Resolution calculus says how to validate paths but not how to find them

• and reachability paths can have cycles

Page 158: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm

• Resolution calculus says how to validate paths but not how to find them

• and reachability paths can have cycles

• But there is a terminating resolution algorithm

• for path well-foundedness RP*I*D

• and path ordering D<I<P

Page 159: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm

• Resolution calculus says how to validate paths but not how to find them

• and reachability paths can have cycles

• But there is a terminating resolution algorithm

• for path well-foundedness RP*I*D

• and path ordering D<I<P

• Uses familiar notions of environments and shadowing

Page 160: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v1

imperative language, explained here. The traversal is specified as a collection of(potentially) mutually recursive functions, one or more for each syntactic classof LM. Each function f is defined by a set of clauses [[pattern]]f

args

. When f isinvoked on a term, the clause whose pattern matches the term is executed. Func-tions may also take additional arguments args. Each clause body consists of asequence of statements separated by semicolons. Functions can optionally returna value using ret(). The let statement binds a metavariable in the remainder ofthe clause body. An empty clause body is written ().

The algorithm is initiated by invoking [[_]]prog on an entire LM program. Itsnet effect is to produce a scope graph via a sequence of imperative operations.The construct new

P

creates a new scope S with parent P (or no parent if p =?)and empty sets D(S), R(S), and I(S). These sets are subsequently populatedusing the += operator, which extends a set imperatively. The program scopegraph is simply the set of scopes that have been created and populated whenthe traversal terminates.

5 Resolution Algorithm

The calculus of Section 2 gives a precise definition of resolution. In principle, wecan search for derivations in the calculus to answer questions such as “Does thisvariable reference resolve to this declaration?” or “Which variable declarationsdoes this reference resolve to?” But automating this search process is not trivial,because of the need for back-tracking and because the paths in reachabilityderivations can have cycles (visiting the same scope more than once), and hencecan grow arbitrarily long.

In this section we describe a deterministic and terminating algorithm forcomputing resolutions, which provides a practical basis for implementing toolsbased on scope graphs, and prove that it is sound and complete with respectto the calculus. This algorithm also connects the calculus, which talks aboutresolution of a single variable at a time, to more conventional descriptions ofbinding which use “environments” or “contexts” to describe all the visible orreachable declarations accessible from a program location.

For us, an environment is just a set of declarations xDi

. This can be thoughtof as a function from identifiers to (possible empty) sets of declaration positions.(In this paper, we leave the representation of environments abstract; in practice,one would use a hash table or other dictionary data structure.) We construct anatomic environment corresponding to the declarations in each scope, and thencombine atomic environments to describe the sets of reachable and visible dec-larations resulting from the parent and import relations. The key operator forcombining environments is shadowing, which returns the union of the declara-tions in two environments restricted so that if a variable x has any declarationsin the first environment, no declarations of x are included from the second envi-ronment. More formally:

Definition 1 (Shadowing). For any environments E1, E2, we write:E1 / E2 := E1 [ {xD

i

2 E2 | @ xDi

0 2 E1}

A Theory of Name Resolution with Extended Coverage and Proofs

18 TUD-SERG-2015-001

where

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

Page 161: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v1

imperative language, explained here. The traversal is specified as a collection of(potentially) mutually recursive functions, one or more for each syntactic classof LM. Each function f is defined by a set of clauses [[pattern]]f

args

. When f isinvoked on a term, the clause whose pattern matches the term is executed. Func-tions may also take additional arguments args. Each clause body consists of asequence of statements separated by semicolons. Functions can optionally returna value using ret(). The let statement binds a metavariable in the remainder ofthe clause body. An empty clause body is written ().

The algorithm is initiated by invoking [[_]]prog on an entire LM program. Itsnet effect is to produce a scope graph via a sequence of imperative operations.The construct new

P

creates a new scope S with parent P (or no parent if p =?)and empty sets D(S), R(S), and I(S). These sets are subsequently populatedusing the += operator, which extends a set imperatively. The program scopegraph is simply the set of scopes that have been created and populated whenthe traversal terminates.

5 Resolution Algorithm

The calculus of Section 2 gives a precise definition of resolution. In principle, wecan search for derivations in the calculus to answer questions such as “Does thisvariable reference resolve to this declaration?” or “Which variable declarationsdoes this reference resolve to?” But automating this search process is not trivial,because of the need for back-tracking and because the paths in reachabilityderivations can have cycles (visiting the same scope more than once), and hencecan grow arbitrarily long.

In this section we describe a deterministic and terminating algorithm forcomputing resolutions, which provides a practical basis for implementing toolsbased on scope graphs, and prove that it is sound and complete with respectto the calculus. This algorithm also connects the calculus, which talks aboutresolution of a single variable at a time, to more conventional descriptions ofbinding which use “environments” or “contexts” to describe all the visible orreachable declarations accessible from a program location.

For us, an environment is just a set of declarations xDi

. This can be thoughtof as a function from identifiers to (possible empty) sets of declaration positions.(In this paper, we leave the representation of environments abstract; in practice,one would use a hash table or other dictionary data structure.) We construct anatomic environment corresponding to the declarations in each scope, and thencombine atomic environments to describe the sets of reachable and visible dec-larations resulting from the parent and import relations. The key operator forcombining environments is shadowing, which returns the union of the declara-tions in two environments restricted so that if a variable x has any declarationsin the first environment, no declarations of x are included from the second envi-ronment. More formally:

Definition 1 (Shadowing). For any environments E1, E2, we write:E1 / E2 := E1 [ {xD

i

2 E2 | @ xDi

0 2 E1}

A Theory of Name Resolution with Extended Coverage and Proofs

18 TUD-SERG-2015-001

where

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

• still need to incorporate “seen imports”

Page 162: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v2

imperative language, explained here. The traversal is specified as a collection of(potentially) mutually recursive functions, one or more for each syntactic classof LM. Each function f is defined by a set of clauses [[pattern]]f

args

. When f isinvoked on a term, the clause whose pattern matches the term is executed. Func-tions may also take additional arguments args. Each clause body consists of asequence of statements separated by semicolons. Functions can optionally returna value using ret(). The let statement binds a metavariable in the remainder ofthe clause body. An empty clause body is written ().

The algorithm is initiated by invoking [[_]]prog on an entire LM program. Itsnet effect is to produce a scope graph via a sequence of imperative operations.The construct new

P

creates a new scope S with parent P (or no parent if p =?)and empty sets D(S), R(S), and I(S). These sets are subsequently populatedusing the += operator, which extends a set imperatively. The program scopegraph is simply the set of scopes that have been created and populated whenthe traversal terminates.

5 Resolution Algorithm

The calculus of Section 2 gives a precise definition of resolution. In principle, wecan search for derivations in the calculus to answer questions such as “Does thisvariable reference resolve to this declaration?” or “Which variable declarationsdoes this reference resolve to?” But automating this search process is not trivial,because of the need for back-tracking and because the paths in reachabilityderivations can have cycles (visiting the same scope more than once), and hencecan grow arbitrarily long.

In this section we describe a deterministic and terminating algorithm forcomputing resolutions, which provides a practical basis for implementing toolsbased on scope graphs, and prove that it is sound and complete with respectto the calculus. This algorithm also connects the calculus, which talks aboutresolution of a single variable at a time, to more conventional descriptions ofbinding which use “environments” or “contexts” to describe all the visible orreachable declarations accessible from a program location.

For us, an environment is just a set of declarations xDi

. This can be thoughtof as a function from identifiers to (possible empty) sets of declaration positions.(In this paper, we leave the representation of environments abstract; in practice,one would use a hash table or other dictionary data structure.) We construct anatomic environment corresponding to the declarations in each scope, and thencombine atomic environments to describe the sets of reachable and visible dec-larations resulting from the parent and import relations. The key operator forcombining environments is shadowing, which returns the union of the declara-tions in two environments restricted so that if a variable x has any declarationsin the first environment, no declarations of x are included from the second envi-ronment. More formally:

Definition 1 (Shadowing). For any environments E1, E2, we write:E1 / E2 := E1 [ {xD

i

2 E2 | @ xDi

0 2 E1}

A Theory of Name Resolution with Extended Coverage and Proofs

18 TUD-SERG-2015-001

where

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

Page 163: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v2

imperative language, explained here. The traversal is specified as a collection of(potentially) mutually recursive functions, one or more for each syntactic classof LM. Each function f is defined by a set of clauses [[pattern]]f

args

. When f isinvoked on a term, the clause whose pattern matches the term is executed. Func-tions may also take additional arguments args. Each clause body consists of asequence of statements separated by semicolons. Functions can optionally returna value using ret(). The let statement binds a metavariable in the remainder ofthe clause body. An empty clause body is written ().

The algorithm is initiated by invoking [[_]]prog on an entire LM program. Itsnet effect is to produce a scope graph via a sequence of imperative operations.The construct new

P

creates a new scope S with parent P (or no parent if p =?)and empty sets D(S), R(S), and I(S). These sets are subsequently populatedusing the += operator, which extends a set imperatively. The program scopegraph is simply the set of scopes that have been created and populated whenthe traversal terminates.

5 Resolution Algorithm

The calculus of Section 2 gives a precise definition of resolution. In principle, wecan search for derivations in the calculus to answer questions such as “Does thisvariable reference resolve to this declaration?” or “Which variable declarationsdoes this reference resolve to?” But automating this search process is not trivial,because of the need for back-tracking and because the paths in reachabilityderivations can have cycles (visiting the same scope more than once), and hencecan grow arbitrarily long.

In this section we describe a deterministic and terminating algorithm forcomputing resolutions, which provides a practical basis for implementing toolsbased on scope graphs, and prove that it is sound and complete with respectto the calculus. This algorithm also connects the calculus, which talks aboutresolution of a single variable at a time, to more conventional descriptions ofbinding which use “environments” or “contexts” to describe all the visible orreachable declarations accessible from a program location.

For us, an environment is just a set of declarations xDi

. This can be thoughtof as a function from identifiers to (possible empty) sets of declaration positions.(In this paper, we leave the representation of environments abstract; in practice,one would use a hash table or other dictionary data structure.) We construct anatomic environment corresponding to the declarations in each scope, and thencombine atomic environments to describe the sets of reachable and visible dec-larations resulting from the parent and import relations. The key operator forcombining environments is shadowing, which returns the union of the declara-tions in two environments restricted so that if a variable x has any declarationsin the first environment, no declarations of x are included from the second envi-ronment. More formally:

Definition 1 (Shadowing). For any environments E1, E2, we write:E1 / E2 := E1 [ {xD

i

2 E2 | @ xDi

0 2 E1}

A Theory of Name Resolution with Extended Coverage and Proofs

18 TUD-SERG-2015-001

where

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

• but still might not terminate due to cycles (e.g. consider a scope that imports itself)

Page 164: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v32

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

Page 165: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v3

Lemma: visibility paths never have cycles

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

Page 166: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Resolution Algorithm v3

Res[I](xRi

) := {xDj

| 9S s.t. x

Ri

2 R(S) ^ x

Dj

2 EnvV

[{xRi

} [ I, ;](S)}Env

V

[I, S](S) := EnvL

[I, S](S) / EnvP

[I, S](S)Env

L

[I, S](S) := EnvD

[I, S](S) / EnvI

[I, S](S)

EnvD

[I, S](S) :=(

; if S 2 SD(S)

EnvI

[I, S](S) :=

8

<

:

; if S 2 SS

n

EnvL

[I, {S} [ S](Sy

) | yRi

2 I(S) \ I ^ y

Dj

:Sy

2 Res[I](yRi

)o

EnvP

[I, S](S) :=

; if S 2 SEnv

V

[I, {S} [ S](P(S))

Fig. 18. Resolution algorithm

Figure 18 specifies an algorithm Res[I](xRi

) for resolving a reference xRi

to a set ofcorresponding declarations xD

j

. Like the calculus, the algorithm avoids trying touse an import to resolve itself by maintaining a set I of “already seen” imports.The algorithm works by computing the full environment Env

V

[I, S](S) of decla-rations that are visible in the scope S containing xR

i

, and then extracting justthe declarations for x. The full environment, in turn, is built from the more basicenvironments Env

D

of immediate declarations, EnvI

of imported declarations,and Env

P

of lexically enclosing declarations, using the shadowing operator. Theorder of construction matches both the WF restriction from the calculus, whichprevents the use of parent after an import, and the path ordering <, whichprefers immediate declarations over imports and imports over declarations fromthe parent scope. (Note that the algorithm does not work for the variants of WFand < described in Section 2.5.) A key difference from the calculus is that theshadowing operator is applied at each stage in environment construction, ratherthan applying the visibility criterion just once at the “top level” as in calculusrule V . This difference is a natural consequence of the fact that the algorithmcomputes sets of declarations rather than full derivation paths, so it does notmaintain enough information to delay the visibility computation.

Termination The algorithm is terminating using the well-founded lexicographicmeasure (|R(G) \ I|, |S(G) \ S|). Termination is straightforward by unfolding thecalls to Res in Env

I

and then inlining the definitions of EnvV

and EnvL

: thisgives an equivalent algorithm in which the measure strictly decreases at everyrecursive call.

5.1 Correctness of Resolution Algorithm

The resolution algorithm is sound and complete with respect to the calculus.

Theorem 1. 8 I, xRi

, j, (xDj

2 Res[I](xRi

)) () (9p s.t. I ` p : xRi

7�! xDj

).

We sketch the proof of this theorem here; details of the supporting lemmasand proofs are in Appendix B. To begin with, we must deal with the fact that

A Theory of Name Resolution with Extended Coverage and Proofs

TUD-SERG-2015-001 19

Theorem: algorithm is sound and complete for calculus:

Lemma: visibility paths never have cycles

2

ED[I, S](S) :=

(

; if S 2 SD(S)

EP [I, S](S) :=

; if S 2 SEV [I, {S} [ S](P(S))

EI [I, S](S) :=

8

<

:

; if S 2 SS

n

EL[I, {S} [ S](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I, S](S) := ED[I, S](S) / EI [I, S](S)

EV [I, S](S) := EL[I, S](S) / EP [I, S](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I, ;](S)}

ED[I](S) := D(S)

EP [I](S) := EV [I](P(S))

EI [I](S) :=S

n

EL[I](Sy) | yRi 2 I(S) \ I ^ y

Dj :Sy 2 Resolve[I](yR

i )o

EL[I](S) := ED[I](S) / EI [I](S)

EV [I](S) := EL[I](S) / EP [I](S)

Resolve[I](xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV [{xR

i } [ I](S)}

ED(S) := D(S)

EP (S) := EV (P(S))

EI(S) :=S

n

EL(Sy) | yRi 2 I(S) ^ y

Dj :Sy 2 Resolve(yR

i )o

EL(S) := ED(S) / EI(S)

EV (S) := EL(S) / EP (S)

Resolve(xRi ) := {xD

j | 9S s.t. x

Ri 2 R(S) ^ x

Dj 2 EV (S)}

Page 167: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Language-independent 𝜶-equivalenceProgram 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

Page 168: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 169: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Page 170: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

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

Preserving ambiguity

Page 171: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Applying Scope Graphs

(ongoing work)

Page 172: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Validation

Page 173: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• 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 - …

Validation

Page 174: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• 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 - …

Validation

• Next goal: fully model some real languages - Java - ML - …

Page 175: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Generating Scope Graphs from AST

[[ds]]prog := P (S) := ? ^ [[ds]]decl⇤

S (new S)

[[moduleXi {ds}]]decls := X

Di :S

0 2 D(s) ^ P (S0) := s ^ [[ds]]decl⇤

S0 (new S

0)

[[import Xs.Xi]]decl

s := X

Ri 2 I(s) ^ [[Xs.Xi]]

qid

s

[[def b]]decls := [[b]]binds,s

[[xi = e]]bindsr,sd := x

Di 2 D(sd) ^ [[e]]expsr

[[xi]]qid

s := x

Ri 2 R(s)

[[fun (xi:t){e}]]exps := P (S0) := s ^ x

Di 2 D(S0) ^ [[e]]expS0 (new S

0)

[[letrec bs in e]]exps := P (S0) := s ^ [[bs]]bind⇤

S0,S0 ^ [[e]]expS0 (new S

0)

[[letpar bs in e]]exps := P (S0) := s ^ [[bs]]bind⇤

S,S0 ^ [[e]]expS0 (new S

0)

[[Xs.xi]]exp

s := [[Xs.xi]]qid

s

[[e1 e2]]exp

s := [[e1]]exp

s ^ [[e2]]exp

s

Authors: Hendrik van Antwerpen, Pierre Neron, Andrew Tolmach, Eelco Visser, GuidoWachsmuth

2 2015/6/3

generate smallest graph satisfying constraints

Page 176: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding gives TypesStatic 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 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 }

Page 177: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding gives TypesStatic 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 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 }

Page 178: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Binding gives TypesStatic 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 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 }

Page 179: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 180: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 181: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 182: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 183: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 184: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 185: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 186: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 187: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 188: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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

Page 189: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Types give BindingBut 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)

Page 190: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Also in the works...

Page 191: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Also in the works...

Page 192: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Scope graph semantics for binding specification languages (starting with NaBL)

Also in the works...

Page 193: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Scope graph semantics for binding specification languages (starting with NaBL)

• Resolution-sensitive program transformations (e.g. renaming, refactoring)

Also in the works...

Page 194: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

• Scope graph semantics for binding specification languages (starting with NaBL)

• Resolution-sensitive program transformations (e.g. renaming, refactoring)

• Dynamic analogs to static scope graphs

Also in the works...

Page 195: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Use Scope Graphs toDescribe Name Resolution

Page 196: A Theory of Name Resolutionvjovanov.github.io/dsldi-summer-school/materials/...Static Name Resolution module module A def import def def def A B 6 y f fun x + x y x + 3 s s 5 module

Use Scope Graphs toDescribe Name Resolution !!