\documentclass{beamer} \usepackage{amsmath} \usepackage{listings} \title{Real World Haskell:\\ Lecture 3} \author{Bryan O'Sullivan} \date{2009-10-21} \begin{document} \lstset{language=Haskell} \frame{\titlepage} \begin{frame} \frametitle{Types: what's the big deal?} If you've been following along and trying out homework, you're probably intimately familiar with the facts that \begin{itemize} \item Haskell is a statically typed language (it checks types before we run), and \item and it's quite strict about this (it's strongly typed). \end{itemize} \end{frame} \begin{frame} \frametitle{What does ``strongly typed'' actually mean?} \begin{definition} A strong type system \alert{guarantees} that a program cannot contain certain kinds of errors. \end{definition} \vskip12pt Strength and dynamism are more or less \emph{independent} concepts in a type system. \vskip12pt There are degrees of both strength and dynamism in type systems, and often disagreement on both, so the likelihood of confusion when talking to someone about types is high. \end{frame} \begin{frame} \frametitle{Familiar types} Haskell provides a number of types similar to those you'll have seen in other languages: \begin{itemize} \item \lstinline{Int} is a fixed-width signed integer type, usually the system's native word size (32 or 64 bits). \item \lstinline{Char} is a Unicode character. \item \lstinline{Double} is the double-precision floating point integer type, usually 64 bits. \item \lstinline{Integer} is a signed integer type of unbounded size (unbounded if you have infinite memory, that is). \item \lstinline{Bool} is the Boolean type, with possible values \lstinline{True} and \lstinline{False}. \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Expressions and types} Every expression (and hence every value) in Haskell has a type. \vskip12pt The expression \lstinline{'a'} has the type \lstinline{Char}. We can write this as follows: \vskip12pt \begin{lstlisting} a :: Char a = 'a' \end{lstlisting} \vskip12pt You can read the syntax ``\lstinline{::}'' as ``\emph{has the type},'' so: \begin{itemize} \item The notation ``\lstinline{a :: Char}'' is called a \alert{type signature}, and \item has the meaning ``\emph{the expression named} \lstinline{a} \emph{has the type} \lstinline{Char}.'' \end{itemize} \end{frame} \begin{frame} \frametitle{Type inference} Have you noticed that most of the homework answers submitted so far contain no type signatures? \vskip12pt This is because the Haskell compiler \emph{infers} what the type of every expression and definition is. \vskip12pt When you write \lstinline{a = 'a'}, the compiler \emph{knows} that the expression \lstinline{'a'} can \emph{only} have the type \lstinline{Char}, so the variable \lstinline{a} must have this type too. \end{frame} \begin{frame} \frametitle{Type inference and concision} Unlike other statically typed languages you may be familiar with, hand-written type annotations are optional\footnote{Well, they're \emph{almost always} optional.} in Haskell. \vskip12pt This is one of the big factors that lets us write amazingly concise code: \begin{itemize} \item We don't need to tell the compiler what our types are when it can figure this out for itself. \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Functions have types, too} \begin{lstlisting} fact :: Integer -> Integer fact n | n < 0 = error "negative!" | otherwise = go n where go 0 = 1 go i = i * go (i-1) \end{lstlisting} \vskip12pt A ``\lstinline{->}'' symbol in a signature denotes the type of a function. \begin{itemize} \item On the left of the \lstinline{->} is the type of the argument. \item The type on the right is that of the result. \end{itemize} \vskip12pt Read the arrow and its neighbours as ``this is a function \emph{from} the type \lstinline{Integer} \emph{to} the type \lstinline{Integer}.'' \end{frame} \begin{frame}[fragile] \frametitle{Functions with multiple arguments} Suppose we have a function with more than one argument. Here's how we write its type signature. \vskip12pt \begin{lstlisting} cons :: Char -> String -> String cons x xs = x : xs \end{lstlisting} \vskip12pt Every item in the chain of arrows, except the last, is the type of the argument at that position. The last item in the chain is the type of the result. \vskip12pt \begin{itemize} \item What is the type of \lstinline{x} above? \item What is the type of \lstinline{xs}? \item What is the function's result type? \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Tuples} An easy way to create a collection of values is using a \emph{tuple}. \vskip12pt \begin{lstlisting} blargle :: (Char, Int, Bool) blargle = ('a', 42, False) \end{lstlisting} \vskip12pt The type signature (optional, as usual!) indicates what the type of each element in the tuple is. \begin{itemize} \item A tuple of two elements is usually called a \emph{pair}. \item Tuples with three elements are often called \emph{triples}. \item Larger tuples are 4-tuples, 5-tuples, and in general, $n$-tuples. (But 4-tuples and larger are very rare in the wild.) \end{itemize} There is no one-tuple type (it would be redundant). \end{frame} \begin{frame} \frametitle{More about tuples} It should be obvious that the following two tuple types can express different numbers of values: \begin{itemize} \item \lstinline{(Bool, Bool)} \item \lstinline{(Bool, Bool, Char)} \end{itemize} As far as the type checker is concerned, they are indeed completely distinct types. \vskip12pt This suggests that the following expressions might have different types: \begin{itemize} \item (True, 'a') \item ('a', True) \end{itemize} What do you think? \end{frame} \begin{frame}[fragile] \frametitle{Functions on tuples} Pairs are so common in Haskell that there are built-in functions, \lstinline{fst} and \lstinline{snd} for accessing the first and second elements of a pair: \vskip12pt \begin{lstlisting} fst (1, 'a') ==> 1 snd (1, 'a') ==> 'a' \end{lstlisting} \end{frame} \begin{frame}[fragile] \frametitle{Pattern matching on tuples} For larger tuples, built-in accessor functions are \emph{not} supplied, since those types are used much less often. \vskip12pt You can define your own functions using pattern matching, and the syntax is as you'd expect: \vskip12pt \begin{lstlisting} fst3 (a,b,c) = a snd3 (a,b,c) = b thd3 (a,b,c) = c \end{lstlisting} \vskip12pt In practice, it's more common to pattern-match than to define and use accessor functions. \end{frame} \begin{frame}[fragile] \frametitle{The list type} The \texttt{ghci} interpreter has a very useful command, \texttt{:type}, for figuring out what the type of an expression or function is. \vskip12pt Here's an example: \begin{verbatim} Prelude> :type lines lines :: String -> [String] \end{verbatim} As this suggests, the notation for ``list of \lstinline{String}'' is \lstinline{[String]}. \vskip12pt And as the notation suggests, every element in a list must have the same type. \end{frame} \begin{frame}[fragile] \frametitle{Type synonyms} Recall that a Haskell string is just a list of characters. \vskip8pt The type of a list of characters is \lstinline{[Char]}, but we often see \lstinline{String} in type signatures. \vskip8pt There is no magic at work here: \lstinline{String} is just a synonym for \lstinline{[Char]}. The compiler treats them identically. \vskip8pt In fact, we can introduce our own type synonyms at will: \vskip8pt \begin{lstlisting} type StreetNumber = Int type StreetName = String type Address = (StreetNumber, StreetName) \end{lstlisting} \vskip8pt (Think \texttt{typedef}, C programmers!) \end{frame} \begin{frame}[fragile] \frametitle{Functions over lists} Type synonyms are only mildly interesting; I mentioned them mainly to bring the \lstinline{String}~$\equiv$~\lstinline{[Char]} equivalence to the fore. \vskip8pt Here's why: notice that most functions on lists don't seem to care what types the \emph{elements} of those lists have: \vskip8pt \begin{lstlisting} drop 3 [0..10] ==> [3,4,5,6,7] drop 5 "abacinate" ==> "nate" \end{lstlisting} \vskip8pt What's going on here? \end{frame} \begin{frame}[fragile] \frametitle{Polymorphism} Consider the following function definition: \vskip8pt \begin{lstlisting} take n _ | n <= 0 = [] take _ [] = [] take n (x:xs) = x : take (n-1) xs \end{lstlisting} \vskip8pt The \lstinline{take} function never inspects the elements of the list. It neither knows nor cares what they are. \vskip8pt We call functions like this \emph{polymorphic} over the list's elements. \end{frame} \begin{frame}[fragile] \frametitle{Polymorphic type signatures} How do we write the type signature for \lstinline{take}? \vskip8pt \begin{lstlisting} take :: Int -> [a] -> [a] \end{lstlisting} \vskip8pt That name ``\lstinline{a}'' above, inside the list brackets, is a \emph{type variable}. \vskip8pt A type variable lets us say ``I don't know or care what concrete type\footnote{``Concrete type''? Think \lstinline{Int}, \lstinline{Char}, etc.} will be used in this position, so here's a placeholder.'' \end{frame} \begin{frame}[fragile] \frametitle{Multiple type variables} We are not limited to a single type variable in a type signature. \vskip8pt \begin{lstlisting} triple :: a -> b -> c -> (a, b, c) triple x y z = (x, y, z) \end{lstlisting} This means: \begin{itemize} \item The first argument could have any type \lstinline{a}. \item The second argument could have any type \lstinline{b}. This type could be the same as, or different to, \lstinline{a}. \item And the third? You get the idea. \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Functions as parameters} Suppose we want to inspect every element of a list, and drop those that do not suit some criterion. \vskip8pt How should we write the type signature of a function that checks an element of the list? \pause \vskip8pt We're checking some element of type \lstinline{a}, and to indicate whether it passes or fails, we should return a \lstinline{Bool}. So our type is: \pause \vskip8pt \begin{lstlisting} a -> Bool \end{lstlisting} \vskip8pt How would we pass such a predicate\footnote{Fancy language for ``function returning a \lstinline{Bool}.''} as an argument to another function that will perform the filtering? \end{frame} \begin{frame}[fragile] \frametitle{The definition of \lstinline{filter}} Welcome to the world of higher-order programming! \vskip12pt \begin{lstlisting} filter :: (a -> Bool) -> [a] -> [a] filter _ [] = [] filter p (x:xs) | p x = x : filter p xs | otherwise = filter p xs \end{lstlisting} \vskip12pt Higher-order programming occurs when we pass around functions as arguments to other functions. Simple, but \emph{amazingly} powerful! \end{frame} \begin{frame}[fragile] \frametitle{Turning a polymorphic type into another type} Suppose we want to use the \lstinline{take} function on a list of \lstinline{Int} values. \vskip12pt How do we figure out what the type of the function will be when we use it in that context? \vskip12pt Take the type variable \lstinline{a}, and substitute our desired type \lstinline{Int} everywhere. So \begin{lstlisting} take :: Int -> [a] -> [a] \end{lstlisting} when applied to a list of \lstinline{Int} becomes \begin{lstlisting} take :: Int -> [Int] -> [Int] \end{lstlisting} \end{frame} \begin{frame}[fragile] \frametitle{Polymorphism and\,\ldots\,polymorphism} We can do the same rewrite-the-types trick when we want to see what the type of a polymorphic function would be when used with another polymorphic type. \vskip8pt What do I mean by this? Consider \lstinline{take} for lists-of-lists-of-lists. \vskip8pt Let's write a polymorphic list as \lstinline{[b]}, so a polymorphic list of lists is \lstinline{[[b]]}. \vskip8pt We'll thus replace \lstinline{a} with \lstinline{[[b]]} to get this type: \vskip8pt \begin{lstlisting} take :: Int -> [[[b]]] -> [[[b]]] \end{lstlisting} \end{frame} \begin{frame}[fragile] \frametitle{Polymorphism vs type inference (I)} Here's a definition someone wrote for homework, but they got confused along the way, since we hadn't covered types yet: \vskip12pt \begin{lstlisting} nth n [] = [] nth n (x:xs) | n < 0 = [] | n == 0 = x | otherwise = nth (n-1) xs \end{lstlisting} \vskip12pt Try reasoning about this code. \begin{itemize} \item What was the intended type for the \lstinline{nth} function? \item What is the type of this version, and why? \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Polymorphism vs type inference (II)} The original type for nth should have been this: \vskip12pt \begin{lstlisting} nth :: Int -> [a] -> a \end{lstlisting} \vskip12pt But because we didn't supply a type, and the code wasn't quite doing the right thing, the compiler inferred a surprising type: \vskip12pt \begin{lstlisting} nth :: Int -> [[a]] -> [a] \end{lstlisting} \vskip12pt Notice that its inference was both \emph{correct} and \emph{consistent} with what the code was really doing (but not with what the author initially \emph{thought} the code was doing). \end{frame} \begin{frame} \frametitle{How does this work in practice?} In real-world code, when you omit type signatures, you place \emph{no constraints} on the compiler's type inference engine. \begin{itemize} \item Therefore, a single type error can lead the inference engine off in wild logical directions. \item If your code \emph{passes} the typechecker's scrutiny, you're not out of the woods: it may not behave as you expect, since its types may be different than you thought. \item If your code \emph{fails} to typecheck, the errors are likely to be confusing, since you gave the compiler no hints about what you really meant. \end{itemize} \end{frame} \begin{frame} \frametitle{Polymorphism and type annotations} What does this experience suggest? \begin{itemize} \item Explicit type signatures can actually be useful! \item A signature indicates what type we \emph{think} the code has. \item Type inference occurs \emph{even} when we supply an explicit type. \item If our code's type signature is inconsistent with the type the compiler infers, we will get a useful compilation error. \end{itemize} \end{frame} \begin{frame} \frametitle{Real world use of type annotations} Practical coding tips: \begin{itemize} \item Add type signatures to almost all of your top-level definitions. \item They're good for \emph{more} than the compiler---they're invaluable to readers, as documentation of your code's behaviour! \item Let the compiler infer types for almost all local definitions, i.e.~those in \lstinline{let} and \lstinline{where} clauses. \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Inferring behaviour from types} In many cases, we can guess what a function probably does, simply by examining its type (and sometimes its name): \vskip12pt \begin{lstlisting} zip :: [a] -> [b] -> [(a, b)] \end{lstlisting} \pause \vskip12pt \begin{lstlisting} replicate :: Int -> a -> [a] \end{lstlisting} \pause \vskip12pt \begin{lstlisting} splitAt :: Int -> [a] -> ([a], [a]) \end{lstlisting} \end{frame} \begin{frame}[fragile] \frametitle{What polymorphism tells us} When we see a polymorphic function like this: \vskip8pt \begin{lstlisting} myLength :: [a] -> Int \end{lstlisting} \vskip8pt We can make a surprisingly strong statement about its behaviour: \begin{itemize} \item Its behaviour \emph{cannot} be influenced by either the type or the values of the elements in the list it receives. \end{itemize} \vskip8pt Why is this? \pause \begin{itemize} \item Polymorphism is a way of saying ``I cannot know anything about this type, or inspect or manipulate its values.'' \end{itemize} \pause \vskip8pt For example, there's no way to say ``\lstinline{myLength} should return a different result for \lstinline{[Char]} than for \lstinline{[Int]}.'' That's pretty profound! \end{frame} \begin{frame}[fragile] \frametitle{Homework (I)} Write a function that drops every $n$th element from a list. It should return the removed elements in one element of a pair, and the remainder of the list in another. Provide a type signature for your function. \begin{lstlisting} every 3 "abcdefghi" ==> ("cfi", "abdegh") \end{lstlisting} \vskip12pt Write a function that returns the $k$th least element of a list, starting from zero as ``the least element''. \begin{lstlisting} kminimum 0 [3,2,1] ==> 1 kminimum 2 "qwerty" ==> 'r' \end{lstlisting} \end{frame} \begin{frame}[fragile] \frametitle{Homework (II)} From inspection of the type and operation of the built-in \lstinline{zipWith} function, write your own implementation. \begin{lstlisting} myZipWith min [1,2,3] [2,2,2,2,2] ==> [1,2,2] \end{lstlisting} \vskip12pt Write a function that capitalizes the first letter of every word in a string. It must preserve whitespace and punctuation. \begin{lstlisting} ucfirst "foo bar!! bAZ" ==> "Foo Bar!! BAZ" \end{lstlisting} \end{frame} \end{document} %%% Local Variables: %%% mode: latex %%% TeX-master: t %%% TeX-PDF-mode: t %%% End: