cs-4400-sp26

Lecture 7: Introduction to Types

To cover:

• What are types?
  • “Static” properties of programs
  • Types as classes of values
• Designing a type system
  • Key property: program is in a type <-> it runs to a value of that type
  • Soundness and completeness
• Inference rules for a type system
  • IfLang with numbers and booleans
  • Checking soundness and completeness
• Writing a type checker in Plait
  • Translating inference rules to code
• If time: scope checking

What are types?

• Informally, in programming: static checks on programs that help us reduce runtime errors
  • Terminology: statics and dynamics <- semantics of programs
    • Akin to “compile time” vs “runtime”
  • What kinds of runtime errors can type systems eliminate?
    • Null pointer exception (option types)
    • Applying non-functions
    • Using fields in a struct/object that don’t exist
    • Array index out of bounds?
    • “wrong behavior” that isn’t regarded that way by the language runtime?
      • Recall [] + []
      • Applying function to wrong arguments/in wrong order
    • Non-exhaustive pattern matching?
• More formally, for this class:
  • Classes of values that programs can run to
  • Focus on type structure (e.g. tuple, function, list, etc.) over base types (number, bool, string, etc.)

Designing type systems

Desired properties:

• Soundness: “well-typed programs don’t go wrong”
  • See also: “make illegal states unrepresentable”; “correctness-by-construction”
• Completeness: “programs that don’t go wrong are well-typed”?
  • Some caveats: not always possible
  • Alternative: Expressiveness: the “programs we want to write” typecheck
• Efficiency: (aka “static”ness:) can’t just run the program and look at the value

We will define a typing judgment e : t that says when an expression e is in a type t. Note that this is a different activity from writing a type checker or type inferencer, which are algorithms for saying yes/no for a given expression/type pair, or for producing a type for a given expression, respectively. Writing e : t declaratively, with inference rules, is an easier task.

Formal statements of soundness and completeness:

• If e : t and e ==> v then v : t.
• If e ==> v and v : t then e : t.

Inference rules for a type system

Syntax: e ::= num n | tt | ff | e + e | if e then e else e

Values: e value

---------      ----------     ---------------
tt value        ff value       (num n) value

Types:

• tt and ff are the values in the Bool type
• (num n) are the values in the Number type

Types t ::= Number | Boolean

Typing rules: Judgment form: e : t

--------- ty/tt      ----------- ty/ff    ------------------ ty/n
tt : Bool             ff : Bool            (num n) : Number

e1 : Number     e2 : Number
--------------------------- ty/+
   (e1 + e2) : Number
   
e : Bool     e1 : t     e2 : t
------------------------------- ty/if
   if e then e1 else e2 : t

Example typing derivation:

Expression: (if ff then 1 else 0) + (2 + 3) : ?

Derivation:

--------- ty/ff  --------- ty/n  --------- ty/n      -------- ty/n  ----- ty/n
ff : Bool        1 : Number       0 : Number         2 : Number    3 : Number
-------------------------------------------- ty/if    ------------------- ty/+
(if ff then 1 else 0) : Number                          (2 + 3) : Number
---------------------------------------------------------------------------- ty/+
(if ff then 1 else 0) + (2 + 3) : Number

Example ill-typed terms:

• (if ff then 1 else tt)
• 4 + tt
• if (if tt then 4 else 5) then tt else ff

Exercise: check (informally) that our inference rules cannot type these programs.

Writing a typechecker in Plait

• See lec7-iflang-typecheck.rkt
• Together:
  • Type checking vs. type synthesis (inference)
    • What are their respective Plait types?

Scope checking

If we have time, we will consider let-expressions and their binding structure in the context of type systems.