1 / 35

David Evans cs.virginia/~evans

Lecture 14: Types of Types. “It would appear that we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements, as they tend to sound pretty silly in five years.” John Von Neumann, 1949. David Evans

josephhoward
Download Presentation

David Evans cs.virginia/~evans

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 14: Types of Types “It would appear that we have reached the limits of what it is possible to achieve with computer technology, although one should be careful with such statements, as they tend to sound pretty silly in five years.” John Von Neumann, 1949 David Evans http://www.cs.virginia.edu/~evans CS655: Programming Languages University of Virginia Computer Science

  2. Menu • Latent Types, Dynamic Checking • Manifest Types, Dynamic Checking • Project Kickoff • Manifest Types, Static Checking CS 655: Lecture 14

  3. Types integers in [0, …) Strings secret information Beatle’s Song Titles • Type is any set of values • After Spring Break, we will see a different definition... programs that halt Colors pointers that points to integer that is prime number pointers that points to pointer that points to storage shared by some other pointer CS 655: Lecture 14

  4. Why have types? • Overloading operators + vs. FADD – compiler needs types to figure out what “+” means • Detecting program errors • Better to notice error than report incorrect result • Make programs easier to read, understand and maintain • Better than comments if they are checked and can be trusted • Security • Can use types to constrain the behavior of programs (we’ll see Proof-Carrying Code later…) CS 655: Lecture 14

  5. Taxonomy • Latent vs. Manifest • Are types visible in the program text? • Checked statically vs. checked dynamically • Do you have to run the program to know if it has type errors? • Checked weakly vs. strongly • How strict are the rules for using types? • Meaningless (just matter of degree) • All combinations are (theoretically) possible • Language that is manifest + static + “weak”? • Language that is latent + dynamic + “strong”? CS 655: Lecture 14

  6. Labrador: BARK with Latent Types Instruction ::= STORELocLiteral | HALT | ERROR (Same as BARK) | ADDLoc1Loc2Loc1 gets the value of Loc1 + Loc2. Loc1 and Loc2 must be the same type, result has same type. | MULLoc1Loc2Loc1 gets the value of Loc1 * Loc2. Loc1 and Loc2 must be the same type. | IFLoc1THENLoc1 If value in Loc1 is non-zero, jump to instruction corresponding to value in Loc2. Loc1 and Loc2 must contain integers. Literal ::= IntLiteral | RealLiteral IntLiteral ::= [-]?[0-9][0-9]* Has type integer. RealLiteral ::= [-]?[0-9][0-9]*.[0-9]* Has type real. As companions Labradors are kindly, patient,intelligent and always keen to please. They make perfect family dogs being especially good with children. Walter & Shackles Guide to Dogs CS 655: Lecture 14

  7. Labrador Program [0] STORE R0 3.14159 [1] STORE R1 4 [2] MUL R1 R1 [3] MUL R0 R1 . CS 655: Lecture 14

  8. Operational Semantics: ADD BARK rule: Instructions[PC] = ADDLoc1 Loc2 < Instructions x PC x RegisterFile >  < Instructions x PC’ x RegisterFile’ > where PC’ = PC + 1 RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = if n  Loc1 RegisterFile[Loc1] + RegisterFile[Loc2] What does this mean? CS 655: Lecture 14

  9. Typed Register File C = Instructions x PC x RegisterFile RegisterFile[i] = <type, value> for all integers i type = integer | real value = an integer if type if integer, a real if type is real Assume functions typeof(RegisterFile[i]), valueof(RegisterFile[i]) CS 655: Lecture 14

  10. Operational Semantics: ADDinteger Instructions[PC] = ADDLoc1 Loc2, typeof(RegisterFile[Loc1]) = integer, typeof(RegisterFile[Loc2]) = integer < Instructions x PC x RegisterFile >  < Instructions x PC’ x RegisterFile’ > where PC’ = PC + 1 RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = if n  Loc1 <integer, valueof(RegisterFile[Loc1]) +integer valueof(RegisterFile[Loc2])> CS 655: Lecture 14

  11. Operational Semantics: ADDreal Instructions[PC] = ADDLoc1 Loc2, typeof(RegisterFile[Loc1]) = real, typeof(RegisterFile[Loc2]) = real < Instructions x PC x RegisterFile >  < Instructions x PC’ x RegisterFile’ > where PC’ = PC + 1 RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = if n  Loc1 <real, valueof(RegisterFile[Loc1]) +real valueof(RegisterFile[Loc2])> CS 655: Lecture 14

  12. Strong vs. Weak Typing • What do we have? • Latent, dynamic, “strongly” typed language • To get: latent, dynamic, “weakly” typed language: • Allow ADD and MUL to work on mixed types, result is real, allow IF predicate to be real • Add transition rules for Instructions[PC] = ADDLoc1 Loc2, typeof(RegisterFile[Loc1]) = real, typeof(RegisterFile[Loc2]) = integer etc. CS 655: Lecture 14

  13. Manifest Types Often, however, explicit (manifest) types make programs easier for compilers to read, not easier for humans to read; and explicit (manifest) types are generally cumbersome for the program writer as well. Implicitly (latently) typed programming languages thus have clear advantages in terms of readability and writability. Turbak & Gifford CS 655: Lecture 14

  14. Mastiff: BARK with Manifest Types Program ::= Declaration*Instruction* Declaration ::= TYPELocINTEGERLoc will hold integral values. | TYPELocREALLoc will hold real values. Instruction ::= STORELocLiteralLoc gets the value of Literal. Loc must have been declared with the same type as Literal. … (same as Labrador) Mastiff: An excellent guard dog, yet gentle and affectionate to its family. Walter & Shackles Guide to Dogs CS 655: Lecture 14

  15. Mastiff Program [D0] TYPE R0 REAL [D1]TYPE R1 INTEGER [0] STORE R0 3.14159 [1] STORE R1 4 [2] MUL R1 R1 [3] MUL R0 R1 CS 655: Lecture 14

  16. Input Function: I: Program  C C = Instructions x PC x RegisterFile where Instructions = same as before, PC = 0 RegisterFile[n] = <integer, 0> if TYPE Rn INTEGER is in Declarations RegisterFile[n] = <real, 0.0> if TYPE Rn REAL is in Declarations RegisterFile[n] = <undeclared, 0> for all other integers n RegisterFile[n] = <error, 0> if (TYPE Rn INTEGER and TYPE Rn REAL are in Declarations) CS 655: Lecture 14

  17. STORELoc IntLiteral Instructions[PC] = STORELoc IntLiteral, typeof(RegisterFile[Loc]) = integer < Instructions x PC x RegisterFile >  < Instructions x PC’ x RegisterFile’ > where PC’ = PC + 1 RegisterFile’[n] = RegisterFile[n] if n  Loc RegisterFile’[n] = <integer, value of IntLiteral> if n  Loc CS 655: Lecture 14

  18. Is Dynamic Type Checking Useful? CS 655: Lecture 14

  19. Projects Ideal Project Should: • Contribute to your thesis research work • Lead to a conference paper • Involve something interesting related to programming languages • Not take up all of your time for the rest of the semester Not all projects will be ideal. #1 is beneficial; #2 is optimistic; #3 is required; #4 is optional. CS 655: Lecture 14

  20. Finding a Project Topic • Think about how your research relates to programming languages: • Are there things that you describe in an ad hoc way today, that could be better understood if they were described more precisely? • Are the places where new abstractions (or removing old ones) would help? • Send me an email before March 19 describing your idea CS 655: Lecture 14

  21. Example (Haiyong) • Doing research on packet classification, performance is crucial • Lots of tradeoffs between how you define your packet classifier and how well it performs, some attempts to define high-level languages for packet classifiers, but they are inflexible or inefficient • Project topic: • Design language for defining packet filters that is flexible and extensible, but performs well. CS 655: Lecture 14

  22. If you really can’t find a project related to your research • Try harder • You can: • Partner with someone else doing a project related to their research • Do a project on something else (possibly with other classmates). I have a few ideas. CS 655: Lecture 14

  23. Course Project Calendar • Sunday, 18 Mar (midnight): Send me email about your project idea • Week of 19 Mar - 23 Mar: Project meetings • 26 Mar: Project proposal • 10 Apr: Preliminary project report • 24 Apr and 26 Apr: Presentations • Tuesday, 1 May: Final report due CS 655: Lecture 14

  24. Project Mantras • Choose an ambitious topic, but be realistic about what you can accomplish in 7 weeks • Try to find a topic you will be interested in working on after the class is over to turn into conference paper • Keep me informed on how your project is going and if you run into any problems. Don’t wait until due dates. • Focus on design and understanding – only build things when there is a clear motivation to solve a problem or conducting an experiment. CS 655: Lecture 14

  25. Project Questions Next: static semantics CS 655: Lecture 14

  26. Static Semantics • Static checking = at compile-time • Dynamic checking = at run (simulate)-time • Know a whole program is type-correct without running it • Can make claims about all possible executions • Drawbacks: • May limit expressiveness of types (not everything can be checked statically) • Some type-correct programs may not pass static checking CS 655: Lecture 14

  27. Typing Rules Premise; ...; Premise Conclusion Conclusions are type judgments: A E : T Read: A proves E has type T. Use type okay to mean it type-checks, but has no type. Type environment: A Type bindings: [I1:T1, ..., In:Tn] In (Loc) has type Tn CS 655: Lecture 14

  28. Mastiff Typing Rules true AIntLiteral : integer [int-literal] RealLiteral : real [real-literal] A contains [Loc:T] Loc : T [location] CS 655: Lecture 14

  29. Typing ADD A , A Loc1:integer Loc22:integer [add-integers] A ADD Loc1 Loc2:okay A , A Loc1:real Loc22:real [add-reals] A ADD Loc1 Loc2:okay CS 655: Lecture 14

  30. Typing MUL A , A Loc1:integer Loc22:integer [mul-integers] A MUL Loc1 Loc2:okay A , A Loc1:real Loc2:integer [mul-weak] A MUL Loc1 Loc2:okay CS 655: Lecture 14

  31. Typing IF A , A Loc1:integer Loc2:integer [if] IFLoc1THENLoc2: okay A A , A Loc1:real Loc2:integer [if-weak] IFLoc1THENLoc2: okay A CS 655: Lecture 14

  32. Type Checking • Statement is well-typed if and only if it has a provable type judgment: • Construct a proof tree, where the root is the type judgment for this statement, and leaves are the axioms • Declarations provide the axioms: Declarations = TYPELoci0Ti0; TYPE Loci1Ti1, ...  A = [Loci0: Ti0, Loci1 : Ti1, ... ] CS 655: Lecture 14

  33. [D0] TYPE R0 REAL [D1]TYPE R1 INTEGER [0] STORE R0 3.14159 [1] STORE R1 4 [2] MUL R1 R1 [3] MUL R0 R1 Type Checking Example Check instruction 3: MUL R0 R1 A = [R0: real; R1: integer] from Declarations A contains [R0 : real] R0:real same for R1: integer A , A R0:real R1:integer [mul-weak] A MULR0 R1:okay CS 655: Lecture 14

  34. Summary Java (casts) CLU, Pascal ML Scheme, Smalltalk CS 655: Lecture 14

  35. Charge • Think about project ideas • Spend at least 1½ hours on Thursday just thinking (not reading, not near a computer) • Lots more on types to come... • After Spring Break: • Data Abstraction • CLU: language designed to support methodology based on data abstraction • Reasoning (informally) about data abstractions • Object-Oriented Languages • Later: • How to do static checking with latent types (type reconstruction, type inference) • How to use types for security CS 655: Lecture 14

More Related