Haskell

Basic Typeclasses

To answer the following questions, use :info Type to see what typeclasses Type is an instance of, then use :info TypeClass to see what functions / operators the different typeclasses support.

a. The test False

b. What are the functions that give the ASCII code for a character and give the ASCII character for an integer (if you use a type annotation :: Char)? (I.e., fcn1 'a' yields 97, fcn2 97 :: Char yields 'a'.) Also, what are their types (including the typeclass)?

c. The functions in part (b) are provided by a typeclass that Char is an instance of. What is the typeclass?

More Information (Examples)

For the examples below, assume we've already declared > :set prompt ">" -- normal prompt > :set prompt-cont "| " -- prompt for lines between : { ... }: A. Typechecking: Static, Dynamic, Strong, and Weak (partly LYaH Ch.3?] Static [LYaH Ch.3 pl] vs Dynamic Typechecking (not in LYaH} Haskell uses static types: Type information is calculated using syntactic analysis, without running the program. (I.e., at compile time".) With dynamic types, type information needs to be determined as the program runs. Both static and dynamic typechecking use type information to determine type safety of a program. E.g., to make sure we are always adding together two things that can be added. If you can't guarantee the type safety of an operation, you have to add a runtime check for it. Typically, static typechecking makes compilation slower but execution faster than dynamic typechecking, which can avoid compile-time calculations but might have to include safety tests at runtime. Note a language can have do some typechecking statically and some dynamically; it doesn't have to do just one or the other. Turns out Haskell needs no dynamic type checks. Strong vs Weak Static Typechecking (not in LYaH} The strength or weakness of a typechecker refers to how much type safety the typechecker guarantees. E.g., in C, typechecking is pretty weak because it allows things that aren't necessarily pointer values to be cast as pointer values. In Haskell, typechecking is strong (or more specially, "type-safe"): Passing typechecking guarantees that there won't be any runtime errors caused by incorrect types, so we don't need to run type-safety tests. Since Haskell typechecking is also static, it's the compiler that can avoid generating code for runtime type checks. (With dynamic type-safe code, it's the programmer who doesn't have to add the code.) With strong static typechecking, when you say "x is of type integer", you're guaranteeing that at runtime, no matter what the history of program execution has been, the value of x meets certain criteria, and you can determine this without actually doing any program execution. To ensure this, language designers have to restrict the ways that values can be created and manipulated. People who like static typechecking are willing to put up with restrictions on how they write code and with extra work getting code to compile because they get better type safety as a result'. Strong vs Weak Dynamic Typechecking (not in LYaH} Languages with dynamic typechecking generally have fewer restrictions in how you write your code. People who like dynamic typechecking like this aspect of a language and are willing to put up with execution requiring safety tests. With strong dynamic typechecking, you perform enough runtime tests before every operation to guarantee that the operation is type-safe. (So, you want to add x and y? Let's make sure they both support addition first.) Note in the best case, the safety tests aren't needed because your program always creates type-safe data. In that case, you can turn off the safety tests and get the speed of statically typechecked code along with faster compilation. This is weak dynamic typechecking (well, non-existent dynamic typechecking). Of course, in the non-best case, turning off the safety tests causes unexpected runtime errors. Since full type safety only happens if all possible code execution sequences are type-safe, just having a program run correctly for ten years doesn't guarantee that it will run correctly tonight: Some never-before- seen input might cause a never-before-used sequence of execution that causes an error. Life being the way it is, this sort of thing really does happen. For the examples below, assume we've already declared > :set prompt ">" -- normal prompt > :set prompt-cont "| " -- prompt for lines between : { ... }: A. Typechecking: Static, Dynamic, Strong, and Weak (partly LYaH Ch.3?] Static [LYaH Ch.3 pl] vs Dynamic Typechecking (not in LYaH} Haskell uses static types: Type information is calculated using syntactic analysis, without running the program. (I.e., at compile time".) With dynamic types, type information needs to be determined as the program runs. Both static and dynamic typechecking use type information to determine type safety of a program. E.g., to make sure we are always adding together two things that can be added. If you can't guarantee the type safety of an operation, you have to add a runtime check for it. Typically, static typechecking makes compilation slower but execution faster than dynamic typechecking, which can avoid compile-time calculations but might have to include safety tests at runtime. Note a language can have do some typechecking statically and some dynamically; it doesn't have to do just one or the other. Turns out Haskell needs no dynamic type checks. Strong vs Weak Static Typechecking (not in LYaH} The strength or weakness of a typechecker refers to how much type safety the typechecker guarantees. E.g., in C, typechecking is pretty weak because it allows things that aren't necessarily pointer values to be cast as pointer values. In Haskell, typechecking is strong (or more specially, "type-safe"): Passing typechecking guarantees that there won't be any runtime errors caused by incorrect types, so we don't need to run type-safety tests. Since Haskell typechecking is also static, it's the compiler that can avoid generating code for runtime type checks. (With dynamic type-safe code, it's the programmer who doesn't have to add the code.) With strong static typechecking, when you say "x is of type integer", you're guaranteeing that at runtime, no matter what the history of program execution has been, the value of x meets certain criteria, and you can determine this without actually doing any program execution. To ensure this, language designers have to restrict the ways that values can be created and manipulated. People who like static typechecking are willing to put up with restrictions on how they write code and with extra work getting code to compile because they get better type safety as a result'. Strong vs Weak Dynamic Typechecking (not in LYaH} Languages with dynamic typechecking generally have fewer restrictions in how you write your code. People who like dynamic typechecking like this aspect of a language and are willing to put up with execution requiring safety tests. With strong dynamic typechecking, you perform enough runtime tests before every operation to guarantee that the operation is type-safe. (So, you want to add x and y? Let's make sure they both support addition first.) Note in the best case, the safety tests aren't needed because your program always creates type-safe data. In that case, you can turn off the safety tests and get the speed of statically typechecked code along with faster compilation. This is weak dynamic typechecking (well, non-existent dynamic typechecking). Of course, in the non-best case, turning off the safety tests causes unexpected runtime errors. Since full type safety only happens if all possible code execution sequences are type-safe, just having a program run correctly for ten years doesn't guarantee that it will run correctly tonight: Some never-before- seen input might cause a never-before-used sequence of execution that causes an error. Life being the way it is, this sort of thing really does happen