Whatever the function does... it has something of one type and returns something of another type (it could be the same type, but doesn't need to). That's all we know.
Now you know how a regular function looks like, e.g:
\begin{haskellcode}
f :: Int -> Int
f x = x + 1
\end{haskellcode}
But now imagine we need a helper function which is very specific to the current function. In C we would have to define this new helper function at top-level and would probably make it \code{static}.
\pause
\vspace{\baselineskip}
\\
Haskell allows us to \textbf{inline} functions in a few more ways, e.g.:
\begin{itemize}[<+->]
\item with \code{where}
\item with \code{let...in}
\item anonymously (lambda abstraction)
\end{itemize}
\onslide<+->
A lot of Haskellers really dislike if you put non-generic functions at the top level. So you can still have atomic pieces, but inline the parts which are very specific to the current function.
These look almost the same, but they are different constructs. \code{where} is bound to the pattern matching \code{f x =} and may also have access to parts of a function that are not syntactically expressions, e.g.:
While that is not possible with \code{let}, which is an actual expression and can be used whenever expressions are allowed (e.g. inside \emph{Monads}, we'll know more about these in a few weeks).
This is what actually makes haskell such a fine functional language. You might have noticed that I tried hard to not show type signatures of functions that have more than one argument. Well, that's because we have to dig a little deeper to explain what comes next:
\pause
\begin{haskellcode}
addInt :: Int -> Int -> Int
addInt x y = x + y
\end{haskellcode}
\pause
So, what is happening here? You probably expected something like:
Currying is actually a mathematical thing and is the technique of translating the evaluation of a function that takes multiple arguments (or a tuple) into evaluating a sequence of functions, each with a single argument.
$z = f(x, y)$ is 3-dimensional. If you fix the variable $x$ you'll make things 2-dimensional (the intersecting plane). If you then fix $y$ you'll get an actual point $z$.
Did you just notice the braces? They are \textbf{very} important! So, currying is \emph{right}-associative which means that these two signatures are equivalent:
\begin{haskellcode}
f :: Int -> Int -> Int
f :: Int -> (Int -> Int)
\end{haskellcode}
On the other hand function application is \emph{left}-associative, so \code{f 3 2} is just a shorthand of \code{(f 3) 2}. Makes sense?
What does that mean for us? It's not just fun stuff or aesthetic. It allows us to do \textbf{partial application}. That means we do not have to give a function all arguments. If we pass an "insufficient" number of arguments it will just give us a new function! Here:
\pause
\begin{haskellcode}
addInt :: Int -> Int -> Int
addInt x y = x + y
addTwo :: Int -> Int
addTwo = addInt 2
\end{haskellcode}
You probably noticed that we did not write \code{addTwo x = ...}, but why would we? We gave \code{addInt} one argument, so the arity (we called it dimension in the gemoetrical example) is one less, but there is still one parameter left we can pass in.
So why did we just bother so long with explaining currying? It's because it's very important for function composition. Which again is also one of the fundamental concepts of functional programming.
\vspace{\baselineskip}
\\
From maths we already know that:\\
$(g \circ f)(x)= g(f(x))$
\vspace{\baselineskip}
\\
\pause
And that's basically it. We do the same in haskell, it looks like this:
\begin{haskellcode}
composedFunction x = (f . g) x
-- same as above... everything on the right side of $
-- is evaluated first
composedFunction x = f . g $ x
-- and same again, remember that 'f x ='
-- is just syntax sugar
-- omitting the x here is also called eta reduction
\textbf{Exercise:} Find the answer! 5 minutes time, remember the \emph{cons} operator \code{(:)}, pattern matching on lists and ofc recursion! Start with the case of an empty list.
All those 3 functions look almost the same. Since haskell is about abstraction, we would never really write any of those like that. Instead, we will write a function that generalizes all 3.
\vspace{\baselineskip}
\\
\pause
I'll give you the type signature, can you guess how the implementation looks like?
\begin{haskellcode}
map :: (a -> b) -> [a] -> [b]
\end{haskellcode}
Solution?
\pause
\begin{haskellcode}
map :: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = f x : map f xs
\end{haskellcode}
So we don't really know what the function \code{f} does, but we know that it converts one element of the list to something else. We \emph{map} a function over a list! Hence the name.
Cool, right? So now we have abstracted out the \textbf{recursion pattern} that is all the same for those 3 functions. \code{map} is actually part of the standard library (called \emph{Prelude}).
Imagine we want to filter all even numbers of a list and throw away all others. I'll give you the type signature:
\begin{haskellcode}
filterEven :: [Int] -> [Int]
\end{haskellcode}
Solution?
\pause
\begin{haskellcode}
filterEven :: [Int] -> [Int]
filterEven [] = []
filterEven (x:xs)
| even x = x : filterEven xs
| otherwise = filterEven xs
\end{haskellcode}
\pause
Or: filter out all 0's, so we can count them later:
\begin{haskellcode}
filterZero :: [Int] -> [Int]
filterZero [] = []
filterZero (x:xs)
| x == 0 = x : filterZero xs
| otherwise = filterZero xs
\end{haskellcode}
Again: do you notice something?
\end{frame}
\begin{frame}[fragile]
\frametitle{6.2. filter (ctn.)}
Let's abstract out the common pieces! This will be our type signature:
\begin{haskellcode}
filter :: (a -> Bool) -> [a] -> [a]
\end{haskellcode}
Solution?
\pause
\begin{haskellcode}
filter :: (a -> Bool) -> [a] -> [a]
filter f [] = []
filter f (x:xs)
| f x = x : filter f xs
| otherwise = filter f xs
\end{haskellcode}
Again: this function is part of the \emph{Prelude} as well.
\end{frame}
\subsection{6.3. fold}
\begin{frame}[fragile]
\frametitle{6.3. fold}
There's one more important recursion pattern. Imagine you want the sum of all numbers of a list, so the function type signature would be:
\begin{haskellcode}
sum :: [Int] -> Int
\end{haskellcode}
Solution?
\pause
\begin{haskellcode}
sum :: [Int] -> Int
sum [] = 0
sum (x:xs) = x + sum xs
\end{haskellcode}
\pause
Or the product:
\begin{haskellcode}
prod :: [Int] -> Int
prod [] = 1
prod (x:xs) = x * prod xs
\end{haskellcode}
\pause
Or the length:
\begin{haskellcode}
length :: [a] -> Int
length [] = 0
length (x:xs) = 1 + length xs
\end{haskellcode}
\end{frame}
\begin{frame}[fragile]
\frametitle{6.3. fold (ctn.)}
To cut the story short, the abstract solution looks like this:
\begin{haskellcode}
fold :: b -> (a -> b -> b) -> [a] -> b
fold z f [] = z
fold z f (x:xs) = f x (fold z f xs)
\end{haskellcode}
Whoa! What's going on here?\\
Let's see...
\begin{itemize}[<+->]
\item\code{z} is what we return if the list is empty
\item\code{f} is our function (e.g. \code{(*)} or \code{(+)})
\item and the last remaining argument is the actual list we are working on
\end{itemize}
\onslide<+->
The function application has the following form:\\
\code{fold f z [a,b,c] == a `f` (b `f` (c `f` z))}
\vspace{\baselineskip}
\\
This folds from the right, so the \emph{Prelude} already defines a function which is very similar to ours and called \textbf{foldr}.
\end{frame}
\begin{frame}[fragile]
\frametitle{6.3. fold (ctn.)}
So how do our \code{sum}, \code{prod} and \code{length} functions look like if we use our \code{fold} abstraction?
\pause
\begin{haskellcode}
sum :: [Int] -> Int
sum xs = fold 0 (\x y -> x + y) xs
-- a Haskeller would write
sum = fold 0 (+)
prod :: [Int] -> Int
prod xs = fold 1 (\x y -> x * y) xs
length :: [a] -> Int
length xs = fold 0 (\x y -> 1 + y) xs
\end{haskellcode}
\end{frame}
\begin{frame}[fragile]
\frametitle{6.3. fold (ctn.)}
There is also a function that folds from the \emph{left} which is also in the \emph{Prelude} and called \textbf{foldl}.\\
To summarize:
\begin{haskellcode}
foldr f z [a,b,c] == a `f` (b `f` (c `f` z))
foldl f z [a,b,c] == ((z `f` a) `f` b) `f` c
\end{haskellcode}
For \code{foldl} the \code{z} is sort of the starting value.
\vspace{\baselineskip}
\\
\pause
We can even express foldl in terms of foldr and vice versa. If you are interested, have a look here: \url{http://lambda.jstolarek.com/2012/07/expressing-foldl-in-terms-of-foldr/}
\vspace{\baselineskip}
\\
You should definitely look them up in the Prelude and play with them: \url{https://hackage.haskell.org/package/base-4.8.0.0/docs/Prelude.html}
\vspace{\baselineskip}
\\
GHCi...
\begin{haskellcode}
> foldr (-) 0 [1, 2, 3]
> foldl (-) 0 [1, 2, 3]
\end{haskellcode}
\end{frame}
\begin{frame}[fragile]
\frametitle{6.3. summary}
\begin{itemize}[<+->]
\item if you find recurring patterns in your code, abstract them out! Experienced Haskellers avoid explicit recursion, unless the recursion pattern is so complex/specific that an abstraction doesn't make sense.
\item map, filter, fold etc are all dependent on the data type (here: lists). For new data types (e.g. a tree) you can and will write your own recursion abstractions
\item although these functions are so fundamental that they are already implemented for most data types out there
\item the standard module (similar to libc in C):\\\url{https://hackage.haskell.org/package/base-4.7.0.0/docs/Prelude.html}
\item debugging in haskell:\\\url{https://wiki.haskell.org/Debugging}
\end{itemize}
\end{frame}
\subsection{8.2. Sources}
\begin{frame}
\frametitle{8.2. Sources}
\begin{itemize}
\item much content was borrowed or is based on the haskell course from Brent Yorgey:\\\url{https://www.seas.upenn.edu/~cis194/fall14/spring13/lectures.html}
\item a few small pieces from the LYAH book \url{http://learnyouahaskell.com}
\item general information from wikipedia: \\\url{https://en.wikipedia.org}
\item general information from haskell wiki: \\\url{https://wiki.haskell.org}