preemptive type checking in dynamically typed programs
play

Preemptive type checking in dynamically typed programs Neville - PowerPoint PPT Presentation

Jan 06, 2023 •370 likes •1.47k views

Preemptive type checking in dynamically typed programs Neville Grech, Julian Rathke, Bernd Fischer n.grech@ecs.soton.ac.uk Dynamically-typed languages Principal type of a variable is mutated through assignments: def plus2(a): if

  1. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : 3] SG g, RET], SG f, CF f, LG f, HLT]

  2. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : ” h ”] SG g, RET], SG f, CF f, LG f, HLT]

  3. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : ” h ” , g : ” h ”] SG g, RET], SG f, CF f, LG f, HLT]

  4. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : < function ... >, g : ” h ”] SG g, RET], SG f, CF f, LG f, HLT]

  5. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , env = [ tos : < function ... >, f : < LC (I 4), function ... >, g : ” h ”] SG g, RET], SG f, CF f, LG f, HLT]

  6. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : 4 , f : < function ... >, g : ” h ”] SG g, RET], SG f, CF f, LG f, HLT]

  7. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : 4 , f : < function ... >, g : 4] SG g, RET], SG f, CF f, LG f, HLT]

  8. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , LC (I 4), env = [ tos : 4 , f : < function ... >, g : 4] SG g, RET], SG f, CF f, LG f, HLT]

  9. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , env = [ tos : < function ... >, f : < LC (I 4), function ... >, g : 4] SG g, RET], SG f, CF f, LG f, HLT]

  10. Interpretation example [INIT , LC (I 3), LC (S "h"), SG g, MF [INITF , env = [ tos : < function ... >, f : < LC (I 4), function ... >, g : 4] SG g, RET], SG f, CF f, LG f, HLT]

  11. A flow-sensitive type inference algorithm Types of variables are dependent on location. ◮ Therefore, type mappings ( Map Id Type ) are associated with program locations ( Loc ).

  12. A flow-sensitive type inference algorithm Types of variables are dependent on location. ◮ Therefore, type mappings ( Map Id Type ) are associated with program locations ( Loc ). Our type inferencer infers two mappings for every location: infer :: Program -> (Map Loc Mapping, Map Loc Mapping) We refer to the left mapping as p (present): ◮ “The possible types of variables after executing the instruction at location Loc ”

  13. A flow-sensitive type inference algorithm Types of variables are dependent on location. ◮ Therefore, type mappings ( Map Id Type ) are associated with program locations ( Loc ). Our type inferencer infers two mappings for every location: infer :: Program -> (Map Loc Mapping, Map Loc Mapping) We refer to the left mapping as p (present): ◮ “The possible types of variables after executing the instruction at location Loc ” We refer to the right mapping as f (future): ◮ “The possible types that variables will be used as, at locations accessible from Loc , Loc inclusive”

  14. A flow-sensitive type inference algorithm The p mapping is formed mainly by a forward analysis: ◮ Control flow joins introduce union types – since the execution could have come from either way.

  15. A flow-sensitive type inference algorithm The p mapping is formed mainly by a forward analysis: ◮ Control flow joins introduce union types – since the execution could have come from either way. The f mapping is formed mainly by a backwards analysis: ◮ Control-flow splits introduce union types – since we cannot statically say where the execution would proceed.

  16. A flow-sensitive type inference algorithm The p mapping is formed mainly by a forward analysis: ◮ Control flow joins introduce union types – since the execution could have come from either way. The f mapping is formed mainly by a backwards analysis: ◮ Control-flow splits introduce union types – since we cannot statically say where the execution would proceed. Function types are made up of two mappings: ◮ side-effects - types of all variables after invoking the function. Corresponds to p mapping. ◮ constraints - types of all variables for the function to succeed. Corresponds to f mapping.

  17. A flow-sensitive type inference algorithm The p mapping is formed mainly by a forward analysis: ◮ Control flow joins introduce union types – since the execution could have come from either way. The f mapping is formed mainly by a backwards analysis: ◮ Control-flow splits introduce union types – since we cannot statically say where the execution would proceed. Function types are made up of two mappings: ◮ side-effects - types of all variables after invoking the function. Corresponds to p mapping. ◮ constraints - types of all variables for the function to succeed. Corresponds to f mapping. Algorithm is based on low-level dynamically-typed bytecode. At runtime, the source is no longer available.

  18. (Part of) our type definitions data Type = Int | Str | Pr | Bool | NoneType | Undef | Uncons | Err | Fn Mapping Mapping .. .. Concrete types: Runtime values can only have a concrete type.

  19. (Part of) our type definitions data Type = Int | Str | Pr | Bool | NoneType | Undef | Uncons | Err | Fn Mapping Mapping .. .. The type of a variable that has not been defined and initialised is Undef: can only appear in the P environment.

  20. (Part of) our type definitions data Type = Int | Str | Pr | Bool | NoneType | Undef | Uncons | Err | Fn Mapping Mapping .. .. The type of a variable in the F environment is Uncons if this variable is not read

  21. (Part of) our type definitions data Type = Int | Str | Pr | Bool | NoneType | Undef | Uncons | Err | Fn Mapping Mapping .. .. Represents a type error

  22. (Part of) our type definitions data Type = Int | Str | Pr | Bool | NoneType | Undef | Uncons | Err | Fn Mapping Mapping .. .. a function, constraints on existing variables are expressed in the first mapping while side-effects on types are represented in the second mapping.

  23. Typing rules Reduction rules match on instructions, transforming an environment into another: type Mapping = Map Id Type type Env = (Mapping, Mapping) red :: Inst -> Env -> Env

  24. Typing rules Reduction rules match on instructions, transforming an environment into another: type Mapping = Map Id Type type Env = (Mapping, Mapping) red :: Inst -> Env -> Env ◮ The p mapping given to red is the p mapping from the previous location in the program.

  25. Typing rules Reduction rules match on instructions, transforming an environment into another: type Mapping = Map Id Type type Env = (Mapping, Mapping) red :: Inst -> Env -> Env ◮ The p mapping given to red is the p mapping from the previous location in the program. ◮ The f mapping given to red is the f mapping from the next location in the program.

  26. Typing rules Reduction rules match on instructions, transforming an environment into another: type Mapping = Map Id Type type Env = (Mapping, Mapping) red :: Inst -> Env -> Env ◮ The p mapping given to red is the p mapping from the previous location in the program. ◮ The f mapping given to red is the f mapping from the next location in the program. ◮ If next or previous location is more than one location, the mappings are joined into one mapping, introducing union types.

  27. Rules red (LC c) (p,f) = typeof returns the type of a constant

  28. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), typeof returns the type of a constant

  29. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) typeof returns the type of a constant

  30. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), gT gets the type of an identifier from a type mapping

  31. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) gT gets the type of an identifier from a type mapping

  32. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), gT gets the type of an identifier from a type mapping

  33. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), f <+> (tos, gT f x) <+> (x,Uncons)) gT gets the type of an identifier from a type mapping

  34. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), f <+> (tos, gT f x) <+> (x,Uncons)) red (INIT) ( ,f) = (toTypeMap initBindings <+> (ALL,Undef),f) toTypeMap transforms a Id-Value map to Id-Type map

  35. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), f <+> (tos, gT f x) <+> (x,Uncons)) red (INIT) ( ,f) = (toTypeMap initBindings <+> (ALL,Undef),f) red (INITF) ( ,f) = (defaultFnMap, f) defaultFnMap containts the default types for all variables

  36. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), f <+> (tos, gT f x) <+> (x,Uncons)) red (INIT) ( ,f) = (toTypeMap initBindings <+> (ALL,Undef),f) red (INITF) ( ,f) = (defaultFnMap, f) red (RET) (p, ) = (p, defaultFnMap) defaultFnMap containts the default types for all variables

  37. Rules red (LC c) (p,f) = (p <+> (tos, typeof c), f <+> (tos, Uncons)) red (LG x) (p,f) = (p <+> (tos, gT p x), f <+> (x,gT f tos) <+> (tos,Uncons)) red (SG x) (p,f) = (p <+> (x, gT p tos), f <+> (tos, gT f x) <+> (x,Uncons)) red (INIT) ( ,f) = (toTypeMap initBindings <+> (ALL,Undef),f) red (INITF) ( ,f) = (defaultFnMap, f) red (RET) (p, ) = (p, defaultFnMap) red (HLT) (p, ) = (p, Map.fromList [(ALL,Uncons)]) defaultFnMap containts the default types for all variables

  38. More rules red (JP n) env = env

  39. More rules red (JP n) env = env red (JIF n) (p,f) = (p, f <+> (tos, Bool))

  40. More rules red (JP n) env = env red (JIF n) (p,f) = (p, f <+> (tos, Bool)) red (MF pr) (p,f) = where typs=infer pr infer returns all present and future types for all variables for all locations for a particular program

  41. More rules red (JP n) env = env red (JIF n) (p,f) = (p, f <+> (tos, Bool)) red (MF pr) (p,f) = (p <+> (tos, Fn (lst typs ! 0) (fst typs ! (length pr -1))), f) where typs=infer pr infer returns all present and future types for all variables for all locations for a particular program

  42. More rules red (JP n) env = env red (JIF n) (p,f) = (p, f <+> (tos, Bool)) red (MF pr) (p,f) = (p <+> (tos, Fn (lst typs ! 0) (fst typs ! (length pr -1))), f) where typs=infer pr red (CF fn) (p,f) = (pp,Map.fromList [(k,meetType (gT f k) (gT ff k)) | k <- allids f ff]) where (pp,ff)=apply (p,f) (gT p fn) meetType performs an intersection of two types apply introduces contstraints and side effects of a given function to a given environment

  43. Type inference example with loops [INIT , LG true , SG x, LC None , CF randbool , JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  44. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , SG x, LC None , CF randbool , JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  45. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, LC None , CF randbool , JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  46. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , CF randbool , JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  47. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  48. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool JIF 15, LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, SG y, JP 3, HLT]

  49. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool JIF 15, -- TOS:Bool, x:Bool LC None , CF randbool , JIF 12, LC (I 2), SG x, JP 14, LG x, -- x:Bool SG y, -- y:Bool JP 3, HLT] -- TOS:Bool, x:Bool , y:Uninit

  50. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool JIF 15, -- TOS:Bool, x:Bool LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, JP 14, LG x, -- x:Bool SG y, -- y:Bool JP 3, HLT] -- TOS:Bool, x:Bool , y:Uninit

  51. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool JIF 15, -- TOS:Bool, x:Bool LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, -- x:Int JP 14, LG x, -- x:Bool SG y, -- y:Bool JP 3, HLT] -- TOS:Bool, x:Bool , y:Uninit

  52. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool/Int JIF 15, -- TOS:Bool, x:Bool/Int LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, -- x:Int JP 14, LG x, -- x:Bool SG y, -- y:Bool JP 3, HLT] -- TOS:Bool, x:Bool , y:Uninit

  53. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool/Int JIF 15, -- TOS:Bool, x:Bool/Int LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, -- x:Int JP 14, LG x, -- x:Bool/Int SG y, -- y:Bool/Int JP 3, HLT] -- TOS:Bool, x:Bool , y:Uninit

  54. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool/Int JIF 15, -- TOS:Bool, x:Bool/Int LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, -- x:Int JP 14, LG x, -- x:Bool/Int SG y, -- y:Bool/Int JP 3, HLT] -- TOS:Bool, x:Bool/Int, y:Uninit/Int/Bool

  55. Type inference example with loops [INIT , -- true:Bool, y:Uninit LG true , -- TOS:Bool SG x, -- x:Bool LC None , -- TOS:NoneType, randbool: Fn (TOS:NoneType->Bool) CF randbool , -- TOS:Bool, x:Bool/Int JIF 15, -- TOS:Bool, x:Bool/Int LC None , CF randbool , JIF 12, LC (I 2), -- TOS:Int, x:Bool SG x, -- x:Int JP 14, LG x, -- x:Bool/Int SG y, -- y:Bool/Int JP 3, HLT] -- TOS:Bool, x:Bool/Int, y:Uninit/Int/Bool F-environment is done in a similar way, but predominantly using a backwards analysis.

  56. More types The types described here do not really appear at runtime:

  57. More types The types described here do not really appear at runtime: type SetOfType = Set Type data Type = ... The types we described so far

  58. More types The types described here do not really appear at runtime: type SetOfType = Set Type data Type = ... | Union SetOfType Union types, introduced in control flow joins/splits

  59. More types The types described here do not really appear at runtime: type SetOfType = Set Type data Type = ... | Union SetOfType | Inter SetOfType Intersection types, introduced in the F environment by successive function applications that introduce different constraints to the same variable

  60. More types The types described here do not really appear at runtime: type SetOfType = Set Type data Type = ... | Union SetOfType | Inter SetOfType | T Id -- variable types A placeholder for types of variables that cannot be determined at this stage

  61. More types The types described here do not really appear at runtime: type SetOfType = Set Type data Type = ... | Union SetOfType | Inter SetOfType | T Id -- variable types | Aff Type Env Id -- affected types An effect or constraint introduced by a function of a particular type on a variable with identifier Id, under environment Env

  62. Variable/affected types and type evaluation [INIT , MF [INITF , CF g, RET], SG f, MF [INITF , LC (I 3), SG x, RET], SG g, CF f, HLT]

  63. Variable/affected types and type evaluation [INIT , MF [INITF , CF g, RET], SG f, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)) MF [INITF , LC (I 3), SG x, RET], SG g, CF f, HLT]

  64. Variable/affected types and type evaluation [INIT , MF [INITF , CF g, RET], SG f, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)) MF [INITF , LC (I 3), SG x, RET], SG g, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)), g: Fn (x: Uncons -> Int) CF f, HLT]

  65. Variable/affected types and type evaluation [INIT , MF [INITF , CF g, RET], SG f, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)) MF [INITF , LC (I 3), SG x, RET], SG g, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)), g: Fn (x: Uncons -> Int) CF f, -- environment e0 HLT] We evaluate f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T ALL)) under environment 0. g)

  66. Variable/affected types and type evaluation [INIT , MF [INITF , CF g, RET], SG f, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)) MF [INITF , LC (I 3), SG x, RET], SG g, --f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T g) ALL)), g: Fn (x: Uncons -> Int) CF f, -- environment e0 HLT] We evaluate f: Fn (ALL: (Aff (T g) ALL) -> (Aff (T ALL)) under environment 0. g) ALL) in the p env. evaluates to x: ALL:(Aff (T g) Int

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend

Dynamically checking type-correctness of whole programs (work newly in-progress). Stephen Kell

Dynamically checking type-correctness of whole programs (work newly in-progress). Stephen Kell

Dynamically checking type-correctness of whole programs (work newly in-progress). Stephen Kell stephen.kell@cl.cam.ac.uk Computer Laboratory University of Cambridge libcrunch . . . p.1/22 Wanted (naive version): check this! if (obj

281 views • 26 slides
Dynamically checking types, bounds and maybe even more (or: some were meant for C) Stephen

Dynamically checking types, bounds and maybe even more (or: some were meant for C) Stephen

Dynamically checking types, bounds and maybe even more (or: some were meant for C) Stephen Kell stephen.kell@cl.cam.ac.uk Computer Laboratory University of Cambridge 1 Tool wanted (how it all started) if (obj &gt; type == OBJ

863 views • 29 slides
CMSC 430 Introduction to Compilers Spring 2016 Type Systems What is a Type System? A type

CMSC 430 Introduction to Compilers Spring 2016 Type Systems What is a Type System? A type

CMSC 430 Introduction to Compilers Spring 2016 Type Systems What is a Type System? A type system is some mechanism for distinguishing good programs from bad Good programs = well typed Bad programs = ill-typed or not typable

765 views • 57 slides
Run-time type checking of whole programs and other stories . Stephen Kell

Run-time type checking of whole programs and other stories . Stephen Kell

Run-time type checking of whole programs and other stories . Stephen Kell stephen.kell@cl.cam.ac.uk Computer Laboratory University of Cambridge libcrunch . . . p.1/44 Wanted (naive version): check this! if (obj &gt; type == OBJ

572 views • 55 slides
Dynamically Typed Programming Languages Part 1: The Untyped -Calculus Jim Royer CIS 352

Dynamically Typed Programming Languages Part 1: The Untyped -Calculus Jim Royer CIS 352

Dynamically Typed Programming Languages Part 1: The Untyped -Calculus Jim Royer CIS 352 April 16, 2019 Royer Dynamically Typed Programming Languages 1 / 22 Reference Practical Foundations for Programming Languages, 2/e, Part VI:

408 views • 28 slides
Dynamically checking types and bounds with libcrunch Stephen Kell stephen.kell@cl.cam.ac.uk

Dynamically checking types and bounds with libcrunch Stephen Kell stephen.kell@cl.cam.ac.uk

Dynamically checking types and bounds with libcrunch Stephen Kell stephen.kell@cl.cam.ac.uk Computer Laboratory University of Cambridge 1 Tool wanted if (obj &gt; type == OBJ COMMIT) { if (process commit(walker, ( struct commit )obj))

641 views • 62 slides
Static Analysis of Dynamically Typed Languages made Easy Yin

Static Analysis of Dynamically Typed Languages made Easy Yin

Static Analysis of Dynamically Typed Languages made Easy Yin Wang School of Informatics and Computing Indiana University Overview Work done as two internships at

797 views • 65 slides
Type checking COMP 520 Fall 2010 Type checking (2) The type checker has severals tasks:

Type checking COMP 520 Fall 2010 Type checking (2) The type checker has severals tasks:

COMP 520 Fall 2010 Type checking (1) Type checking COMP 520 Fall 2010 Type checking (2) The type checker has severals tasks: determine the types of all expressions; check that values and variables are used correctly; and resolve

631 views • 30 slides
Dynamically diagnosing type errors in unsafe code Stephen Kell stephen.kell@cl.cam.ac.uk

Dynamically diagnosing type errors in unsafe code Stephen Kell stephen.kell@cl.cam.ac.uk

Dynamically diagnosing type errors in unsafe code Stephen Kell stephen.kell@cl.cam.ac.uk Computer Laboratory University of Cambridge 1 A definition ... dynamically type-safe [means] the behavior of any program, correct or not, can be

626 views • 29 slides
i 1 / 61 Introduction and Context 2 / 61 3 / 61 3 / 61 3 / 61 3 / 61 Exotic design rules,

i 1 / 61 Introduction and Context 2 / 61 3 / 61 3 / 61 3 / 61 3 / 61 Exotic design rules,

Representing and Computing with Types in Dynamically Typed Languages Extending Dynamic Language Expressivity to Accommodate Rationally Typed Sequences Jim Edward Newton Thesis defense for the title: Doctorat de lUniversit e Sorbonne

2k views • 178 slides
Type Checking General properties of type systems Types in programming languages

Type Checking General properties of type systems Types in programming languages

Outline Type Checking General properties of type systems Types in programming languages Notation for type rules Logical rules of inference Common type rules 2 Static Checking Static Checking (Cont.) Refers to

896 views • 10 slides
Type Reconstruction and Polymorphism 1 Type Checking and Type Reconstruction We now come to the

Type Reconstruction and Polymorphism 1 Type Checking and Type Reconstruction We now come to the

Type Reconstruction and Polymorphism 1 Type Checking and Type Reconstruction We now come to the question of type checking and type reconstruction. Given , t and T , check whether t : T Type checking: Given and t , find a type T

518 views • 28 slides
Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019

Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019

Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019 Reference Practical Foundations for Programming Languages, 1/e, Part VI: Dynamic Types , by Robert Harper, Cambridge University Press, 2013,

107 views • 9 slides
Higher-Order Model Checking III: Reducing Model Checking to Type Inference IV: Applications:

Higher-Order Model Checking III: Reducing Model Checking to Type Inference IV: Applications:

Higher-Order Model Checking III: Reducing Model Checking to Type Inference IV: Applications: Verifying Higher-order Functional Programs Luke Ong University of Oxford http://www.cs.ox.ac.uk/people/luke.ong/personal/ http://mjolnir.cs.ox.ac.uk

856 views • 26 slides
Type Checking Grammar Rule Semantic Rule var-decl id : type-exp Insert (id.name, type-exp .

Type Checking Grammar Rule Semantic Rule var-decl id : type-exp Insert (id.name, type-exp .

Type Checking Grammar Rule Semantic Rule var-decl id : type-exp Insert (id.name, type-exp . type ) type-exp int type-exp . type := integer type-exp bool type-exp . type := boolean type-exp 1 array type-exp 1 . type := [num] of

613 views • 7 slides
Higher order functions Functions that take other functions as parameters Easily supported

Higher order functions Functions that take other functions as parameters Easily supported

Higher order functions Functions that take other functions as parameters Easily supported in languages that are dynamically typed and where functions treated as a type of data More complex in statically typed languages where functions

239 views • 4 slides
CPSC 213 Introduction to Computer Systems Unit 2b Threads 1 Reading Text Concurrent

CPSC 213 Introduction to Computer Systems Unit 2b Threads 1 Reading Text Concurrent

CPSC 213 Introduction to Computer Systems Unit 2b Threads 1 Reading Text Concurrent Programming with Threads 2ed: 12.3 1ed: 13.3 2 The Virtual Processor Originated with Edsger Dijkstra in the THE Operating System in

635 views • 34 slides
Preemptive Scheduling Scheduler select a READY process and sets it up to run for a maximum of

Preemptive Scheduling Scheduler select a READY process and sets it up to run for a maximum of

Preemptive Scheduling Scheduler select a READY process and sets it up to run for a maximum of Preemptive Scheduling and some fixed time (time-slice) Mutual Exclusion with Hardware Support Scheduled process computes happily, oblivious to

933 views • 6 slides
Part Five : The Disciples Prayer Parents Family Friends Youth leaders SS

Part Five : The Disciples Prayer Parents Family Friends Youth leaders SS

Part Five : The Disciples Prayer Parents Family Friends Youth leaders SS workers Teachers Pastors Every disciple should be discipling someone somewhere Who is this in YOUR life? #truediscipleship

578 views • 20 slides
How to Pray for Healing &amp; Restoration If my people, who are called by my name, will humble

How to Pray for Healing &amp; Restoration If my people, who are called by my name, will humble

How to Pray for Healing &amp; Restoration If my people, who are called by my name, will humble themselves and pray and seek my face and turn from their wicked ways, then I will hear from heaven, and I will forgive their sin and will heal their

442 views • 17 slides
Admission Control over DiffServ using Pre-Congestion Notification Philip Eardley , Bob Briscoe,

Admission Control over DiffServ using Pre-Congestion Notification Philip Eardley , Bob Briscoe,

Admission Control over DiffServ using Pre-Congestion Notification Philip Eardley , Bob Briscoe, Dave Songhurst - BT Research Francois Le Faucheur, Anna Charny Cisco Kwok-Ho Chan, Joe Babiarz - Nortel IETF-64 tsvwg Nov 8 th 2005 Summary

243 views • 13 slides
Line search method for solving a non-preemptive strictly periodic scheduling problem Cl ement

Line search method for solving a non-preemptive strictly periodic scheduling problem Cl ement

Presentation of the problem The heuristic Results and conclusion Line search method for solving a non-preemptive strictly periodic scheduling problem Cl ement Pira and Christian Artigues MOGISA Team, LAAS-CNRS, Toulouse, France August 29,

790 views • 68 slides
[CPU S CHEDULING ] Shrideep Pallickara Computer Science Colorado State University CS370:

[CPU S CHEDULING ] Shrideep Pallickara Computer Science Colorado State University CS370:

CS370: Operating Systems [Fall 2018] Dept. Of Computer Science , Colorado State University CS 370: O PERATING S YSTEMS [CPU S CHEDULING ] Shrideep Pallickara Computer Science Colorado State University CS370: Operating Systems [Fall 2018] October

944 views • 24 slides
Xen 3.0 - What is it? By Luke St.Clair Overview Memory Management Interrupts

Xen 3.0 - What is it? By Luke St.Clair Overview Memory Management Interrupts

Xen 3.0 - What is it? By Luke St.Clair Overview Memory Management Interrupts Device I/O Starvation HVM And so much more... Memory Start of Day - Initial page, and address of the translation Domain builder

562 views • 18 slides

More recommend