Semantic Analysis Aslan Askarov aslan@cs.au.dk Partially based on - - PowerPoint PPT Presentation

semantic analysis
SMART_READER_LITE
LIVE PREVIEW

Semantic Analysis Aslan Askarov aslan@cs.au.dk Partially based on - - PowerPoint PPT Presentation

Compilation 2016 Semantic Analysis Aslan Askarov aslan@cs.au.dk Partially based on slides by E. Ernst Where are we Earlier this week: Abstract syntax trees tree representation of a program Scoping rule how to


slide-1
SLIDE 1

Compilation 2016

Semantic Analysis

Aslan Askarov aslan@cs.au.dk
 
 
 Partially based on slides by E. Ernst

slide-2
SLIDE 2

Where are we

  • Earlier this week:
  • Abstract syntax trees – tree representation of a program
  • Scoping rule – how to interpret declarations
  • Environments – implementation infrastructure
  • Today:
  • Semantic analysis
slide-3
SLIDE 3

Goals of the semantic analysis

  • Checking that input program is well-typed
  • i.e., checking that AST produced by the parser

adheres to the typing rules of the language.

  • Generally, after this phase, most errors are

reported to the user

  • Generating typed-AST for later compiler phases
slide-4
SLIDE 4

From AST to typed-AST

  • Typed AST is an abstract syntax tree decorated

with type information

  • we may also throw away source-level position

information, because it is strictly speaking not needed from this point on

slide-5
SLIDE 5

TigerLight0

  • The language of missing features :)
  • No loops
  • No functions
  • No user-def types
  • types range only over int, string, and unit
  • No arrays or records
  • No references
  • No dangling else
  • Only basic integer operators over expressions

} ⇒ let declarations only include vars

slide-6
SLIDE 6

TigerLight0

let var x : Int := 10 var s : String := “hi” in if x then s else 42 end

Is this program well-typed?

slide-7
SLIDE 7

TigerLight0

>_

slide-8
SLIDE 8

Tiger Types

structure Types : TYPES = struct type unique = unit ref datatype ty = INT | STRING | RECORD of (Symbol.symbol * ty) list * unique | ARRAY of ty * unique | NIL | UNIT | NAME of Symbol.symbol * ty option ref | ERROR (* ambiguity exists due to type error *) end

slide-9
SLIDE 9

Uniqueness: nominal type equivalence

  • Nominal type equivalence known from Java etc.:


class C1 {.. /* some declarations */ ..} 
 class C2 {.. /* identical to C1, rename as needed */ ..}

  • Even though declarations are identical, these classes

are not the same type

  • Tiger uses nominal type eq. for records and arrays:

‘unit ref’ is always a unique value

structure Types : TYPES = struct type unique = unit ref datatype ty = ... | RECORD of (Symbol.symbol * ty) list * unique | ARRAY of ty * unique ... end

slide-10
SLIDE 10

Uniqueness: Quiz

  • Q: How else could you implement this?

another AST traversal

A separate AST traversal to generate unique identifiers for each record/array declaration would be a cleaner implementation approach, but at the cost of writing/maintaining an extra AST pass; so the unit ref hack is okay

TypeDec 'rectype2' RecordTy 'string' 'name' 'arrtype1' 'dates' 238378 unique_id TypeDec 'rectype2' RecordTy 'string' 'name' 'arrtype 1' 'dates'

slide-11
SLIDE 11

Tiger declarations

  • let function = … 


type = 
 …

  • Compared to TigerLight0 semantic analysis for the

full Tiger language needs two environments

  • variable (and function) environment
  • type environment
  • We extend our implementation so transExp and

friends take an extra environment argument
 
 transExp (venv, tenv) exp

slide-12
SLIDE 12

Summary

  • Semantic analysis: Above CFG, general
  • Major element: Type-checking: well-formedness,

representation, choice of variant, …

  • From AST to typed AST
  • Tool: Symbol table (imp./func.), stack discipline
  • Representation of types, environments
  • nominal types
  • Type-checking declarations