Skip to content
GitLab
Explore
Sign in
Primary navigation
Search or go to…
Project
S
sgdt
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Package registry
Model registry
Operate
Environments
Terraform modules
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
gradual-typing
sgdt
Commits
7edc94a2
Commit
7edc94a2
authored
6 years ago
by
Max New
Browse files
Options
Downloads
Patches
Plain Diff
write up my gradual type theory talk notes
parent
7be98f42
No related branches found
No related tags found
No related merge requests found
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
talk/amal-class-spring-2019/gtt-talk.org
+102
-42
102 additions, 42 deletions
talk/amal-class-spring-2019/gtt-talk.org
with
102 additions
and
42 deletions
talk/amal-class-spring-2019/gtt-talk.org
+
102
−
42
View file @
7edc94a2
* Outline
* Outline
** Intro: What semantics of Gradual Typing is Right?
** Intro: What semantics of Gradual Typing is Right?
*** DONE Pop Quiz: How does this program run?
*** DONE Pop Quiz
- (lambda (f : ? -> ?). true) 3
Any answer is good if it can be *justified*. Best justifications
- dynamic typing: evaluates to true
are *violations of soundness theorems*
- almost every gradual language: error: 3 is not ? -> ?
1. How does (lambda (x : ? * Int). true) (3 :: ?) evaluate?
- pi_1 ((lambda (f : ? -> ?). (true, f)) 3)
- dynamic typing: evaluates to true
- why? if we just added a rule that said this
- almost every gradual language: error: 3 is not ? -> ?
- lesson 1: gradual typing introduces errors even when
- pi_1 ((lambda (x : ? * Int). (true, x)) 3)
unneccessary for safety theorems to be true
- most people answered error, but why? doesn't violate a
- λ p : A_1 x A_2. λ f. f (pi1 p)
soundness theorem.
- (λ p : Int x Bool. λ f. f (pi1 p)) ((3, 4) :: ?)
- lesson 1: gradual typing introduces errors even when
- (λ p : Int x Bool. let y = pi1 p in λ f. f y) ((3, 4) :: ?)
unneccessary for safety theorems to be true
- as a general principle, in a typed cbv lang should
2. Are λ p : A_1 x A_2. λ f. let x1,x2 = p in f x1 and
(λ p. λ f. f(pi1 p) == λ p. let y = pi1 p in λ f. f y)
λ p : A_1 x A_2. let x1,x2 = p in λ f. f x1 equivalent?
- lesson 2: we should think about how cast insertion affects the
- not in transient semantics
safety of our operations
- equivalent in stlc
- Julia's example: (((λ x:?. x) :: I -> I) :: ?) :: B -> B
- not space-equivalent: second one x2 is clearly not in f's
- should it
closure
1. be equivalent to (λ x:B. x)
- we want these to be equivalent so we can make this
2. be equivalent to (λ x:B. error)
space-saving optimization
3. be equivalent to `error`?
3. Julia's example: (((λ x:?. x) :: I -> I) :: ?) :: B -> B
*** Why do programs error?
- should it
- Type Safety, Blame safety? neither prevent dropping intermediate
1. be equivalent to (λ x:B. x)
casts
2. be equivalent to (λ x:B. error)
- Let's be positive: types are there to *help us*, to allow us to
3. be equivalent to `error`?
refactor, optimize in a modular way
- what about if instead of that middle cast I was wrapping it in
** Relational Soundness Theorems
a logging function? Loggify(f) = λ x. log(x); f(x)
*** Contextual Equivalence + βη-equivalence
- eager semantics breaks functional reasoning.
*** Graduality as Contextual Approximation
then I promise I will show soundness theorems that give us an
answer to all 3 questions
** What soundness theorems should we want
Gradually typed languages should be
1. Typed: satisfy a type soundness theorem
2. Gradual: satisfy a graduality theorem.
*** Contextual Equivalence
- define contextual equivalence in the presence of divergence and
errors. mention it depends on effects
- sound typing means having reasoning principles for contextual
equivalence: justify compiler and programmer
reasoning/optimization.
**** Pairs
- show intro, elim (pattern match), cbv beta, cbv eta
- note that beta is valid in untyped language
- eta is the difference between typed and untyped reasoning
- note that sums, ints, bools are similar.
- show examples 1 should error because eta says we should be able
to pattern match and example 2 is equivalent by eta.
**** Functions
- show intro, elim, cbv beta, cbv eta
- mention the cbn beta/eta in passing
- "there's nothing more to a function than what happens when you
apply it"
- show that example 3 we should be able to eta expand in the
middle, which rules out an error.
- caveat: not true in the presence of eq?/object identity, but
note that in that case the normal cast semantics isn't valid
either!
*** Graduality
- when I add types, my program should still work
**** Syntactic Type and Term precision
- show normal definition of type precision (everything is
monotone)
- define syntactic term precision as having the same type erasure
and the corresponding annotations are <=.
**** Semantic Term Precision
Modify the definition of contextual equivalence to an ordering.
- graduality is syntactic term precision => semantic term precision
** Gradual Type Theory
** Gradual Type Theory
- Now that we have formulated what we *want* out of gradual
*** Motivation
languages, we can ask: what are the consequences of the
- normally we define our semantics and then prove our soundness
definition? How much design freedom do we really have?
theorems.
- We accomplish this by *axiomatizing* these properties in a type
- with GTT we want to take our soundness theorems as given, and
theory we call Gradual Type Theory
*derive* an operational semantics.
- The result of this axiomatization is that we can *prove*
- how? We show that for (almost) every reduction in the cast
operational reductions follow from our relational soundness
semantics t |-> t', we can *justify* it by showing that t and t'
theorems. So most of the semantics is totally determined.
must be *contextually equivalent* if our type soundness and
*** DONE What to present?
graduality theorems hold.
- Examples
- to make that argument precise we *axiomatize* our type soundness
- beta-eta as ctx equivalences
and graduality theorems in a type theory with a logic for
- graduality as ctx approximation
semantic precision.
- casts as lubs/glbs
*** Basic Rules
- "headline theorem": derive contracts from soundness
- show them the judgmental structure: types, terms, type and term
precision, point out the side-conditions on term precision.
- say that we add congruence rules (encoding syntactic term
precision), and beta-eta.
- add in errors and minimality of error rule.
*** Cast Rules
- motivate: casts should be as similar as possible to the original
- downcasts
- the downcast should be below the original because it may error
but blah
- but with just that the error would be acceptable: need to make
sure it's not too small: make it the largest such thing
- glb
- upcasts
- upcast should be above because its behavior should be related
- but we don't want to hide error behaviors with good behavior:
make sure it's the smallest such thing
- lub
- by defining them as glbs and lubs this is defining them
precisely.
*** Cast Uniqueness Principles
- just had time to show that we can prove an equivalence between
the function cast and a functional implementation of that cast.
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment