CSE 130 Lecture Notes - Lecture 7: Type Inference, Type Safety, Compile Time
15 views3 pages
31 Jan 2018
School
Department
Course
Professor
Types - a way to prevent errors!
Ex: function apply(f, x) { return f(x); } ← what if f is NOT a function??
Ex: apply :: (a -> b) -> a -> b
1) Fix a function
2) Has to return of type ‘a’
3) Has to return of type ‘b’
-prevents meaningless computations from being executed!
-way of static analysis - checking before programs executed
What else are types good for? Organization & documentation
Ex: insert :: k -> Set k -> Set k
-probably adds an element to a set, and returns a NEW set (since its immutable!)
Eg: reading a file
readFile :: FilePath -> IO String
- Expects a “File path”, a well-formatted string (/__/__*)
- Returns a String and also does IO
What else are types good for? A hint to the compiler
Ex: obj.prop1 (prop1 is always some offset of the object in memory)
Who enforces types?
Ex: arr[200]
-What happens in JS if arr is null? undefined/throw exception (runtime)
-what happens in C/C++ if arr is of size 10? Segfault (not always, if other arrays next to arr)
(runtime/hardware (OS))
-what happens in Haskell is arr is NOT an array? (compile time! (statically))
-Answer: depends on the language!
1. Compile-time
2. Runtime
3. Runtime/Hardware
What are the tradeoffs of each?
Compile Runtime Hardware
Pro no runtime permissive fast
Overhead
Con slow @ compile slow (overhead!) too late @ runtime!
Constraints types crashes! (really bad)
PIA (pain in the ass)
Cost of compile-time checking
function f(x) {
Return x < 10 ? x : x();
}