729 lines
24 KiB
TeX
729 lines
24 KiB
TeX
\documentclass[10pt,a5paper,mathserif,serif,usenames,dvipsnames]{beamer}
|
|
|
|
% packages
|
|
\usepackage{xcolor}
|
|
\usepackage[utf8]{inputenc}
|
|
\usepackage{amsmath}
|
|
\usepackage{amsfonts}
|
|
\usepackage{amssymb}
|
|
\usepackage{graphicx}
|
|
\usepackage{listings}
|
|
\usepackage{minted}
|
|
|
|
% for \verb inside \item
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[Q=yes]{examplep}
|
|
|
|
% package configuration
|
|
\DeclareGraphicsExtensions{.pdf,.png,.jpg}
|
|
\beamertemplatenavigationsymbolsempty
|
|
\setbeamertemplate{footline}[frame number]
|
|
\usemintedstyle{friendly}
|
|
\newminted{haskell}{frame=single,numbers=left}
|
|
\newminted{cpp}{frame=single,numbers=left}
|
|
\newminted{c}{frame=single,numbers=left}
|
|
\renewcommand{\theFancyVerbLine}{\ttfamily
|
|
\textcolor[rgb]{0.0,0.0,0.0}{\footnotesize
|
|
\oldstylenums{\arabic{FancyVerbLine}}}}
|
|
|
|
% title page information
|
|
\author{Julian Ospald}
|
|
|
|
\institute{FH Bielefeld}
|
|
\title{Haskell: introduction}
|
|
|
|
% color definition
|
|
\definecolor{solarized}{HTML}{002B36}
|
|
\definecolor{mygreen}{rgb}{0,0.6,0}
|
|
|
|
% macros and environments
|
|
\newcommand{\code}[1]{\texttt{#1}}
|
|
|
|
\begin{document}
|
|
|
|
\frame{\titlepage}
|
|
|
|
\begin{frame}[allowframebreaks=0.7]
|
|
\frametitle{Table of Contents}
|
|
\tableofcontents
|
|
\end{frame}
|
|
|
|
\section{1. Why haskell?}
|
|
|
|
\begin{frame}
|
|
\frametitle{1. Why haskell?}
|
|
A Haskeller might claim: haskell...
|
|
\begin{itemize}[<+->]
|
|
\item eliminates certain classes of bugs
|
|
\item not only disallows bad programs, but also defines what constitutes a bad program
|
|
\item makes it easy to reason about code
|
|
\item decreases the bus-factor
|
|
\item makes it possible to apply huge changes to large programs without worrying about the implicit state machine
|
|
\item makes it easier to program complex problems
|
|
\item allows for clean APIs, even without any OOP
|
|
\item a haskell program of 10K LOC isn't that much different to maintain as a 100K LOC
|
|
\item refactoring in haskell means abstraction
|
|
\end{itemize}
|
|
\vspace{\baselineskip}
|
|
\onslide<+->
|
|
We'll have to see if this holds true.
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{1. Why haskell? (ctn.)}
|
|
From C++ std:
|
|
\begin{cppcode}
|
|
void pop();
|
|
\end{cppcode}
|
|
\onslide<+->
|
|
From the C FLINT library:
|
|
\begin{ccode}
|
|
void fmpz_mod_poly_add(
|
|
fmpz_mod_poly_t res,
|
|
const fmpz_mod_poly_t poly1,
|
|
const fmpz_mod_poly_t poly2);
|
|
\end{ccode}
|
|
\vspace{\baselineskip}
|
|
\onslide<+->
|
|
Regular C functions in real-world (omitting examples on purpose):
|
|
\begin{itemize}[<+->]
|
|
\item 100+ LOC
|
|
\item at least 7 ifs, 4 whiles, 12 variables, 1 goto
|
|
\item accesses both static and global variables
|
|
\item indenting level of 5 or more
|
|
\item a lot of memory management and custom-made error handling
|
|
\item references everywhere!
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{1. Why haskell? (ctn.)}
|
|
You need to change only one single line in such a C function. You have to know:
|
|
\begin{itemize}[<+->]
|
|
\item does the order of function calls matter?
|
|
\item how does the change effect the memory management? Do we have memory leaks? Do we access invalid memory?
|
|
\item does it change the state of static or global variables?
|
|
\item does it implicitly change the state of out-parameters?
|
|
\item if it changes any of those states, is the function still correct?
|
|
\item what happens if the program flow reaches this code-path with variable X in that particular state, while variable Z is NULL, and...
|
|
\item did you just nuke a small former Soviet state?
|
|
\end{itemize}
|
|
\vspace{\baselineskip}
|
|
\onslide<+->
|
|
Conclusion: you really need to understand the complete environment of that line/function.
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{1. Why haskell? (ctn.)}
|
|
But java helps! Does it?
|
|
Sort of, because:
|
|
\begin{itemize}[<+->]
|
|
\item it improves APIs compared to C, since you can hide or encapsulate information in the state of an object
|
|
\item it has a garbage collector, so you don't need to worry too much about memory
|
|
\item an experienced programmer will find it easier to manage side-effects in Java, because you can e.g. have every impure functions throw an IO exception
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{1. Why haskell? (ctn.)}
|
|
Unfortunately, with java we:
|
|
\begin{itemize}[<+->]
|
|
\item now got even more states to keep track of (intellectual complexity?)
|
|
\item have clouded the program flow... it's now about object-interaction with their explicit and implicit states and because of the increase of indirection, it might get even harder to do actual abstraction
|
|
\item still have \textbf{side effects} everywhere: one object changes the state of another and vice versa, may arbitrarily write to the hard drive, do kernel calls or launch a missile
|
|
\end{itemize}
|
|
\onslide<+->
|
|
Some parts of the implicit state machine have been made explicit by modelling classes, but it's still there and we have to deal with it, because we are modelling everything around states. Wouldn't it be nice if we could just forget about the global state machine? Maybe there is even a way to remove side effects and have more "predictability"?
|
|
\onslide<+->
|
|
\\
|
|
\vspace{\baselineskip}
|
|
We are lucky. There is. It's called \textbf{Haskell}.
|
|
\end{frame}
|
|
|
|
\section{2. What is haskell?}
|
|
|
|
\begin{frame}
|
|
\frametitle{2. What is haskell?}
|
|
Haskell is a \textbf{functional}, \textbf{pure}, \textbf{lazy} and \textbf{statically typed} high-level programming language.\\
|
|
\onslide<+->
|
|
\vspace{\baselineskip}
|
|
A few of the following facts will be white lies. But let's not worry about that. It's maybe more about "how to think in terms of haskell?" than "what is haskell?".
|
|
\end{frame}
|
|
|
|
\subsection{2.1. What does functional mean?}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.1. What does \textbf{functional} mean?}
|
|
Think of haskell functions as regular \emph{mathematical} functions.
|
|
\onslide<+->
|
|
\vspace{\baselineskip}
|
|
\includegraphics*[scale=0.4]{function-machine.png}
|
|
\begin{itemize}[<+->]
|
|
\item does this function write to the hard drive?
|
|
\item does the output depend on anything else except the input (e.g. time, environment, ...)?
|
|
\end{itemize}
|
|
\onslide<+->
|
|
\vspace{\baselineskip}
|
|
It's all about \emph{input} and \emph{output} of functions! And that's it. Nothing else to worry about.
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.1. What does \textbf{functional} mean? (ctn.)}
|
|
\begin{itemize}[<+->]
|
|
\item \emph{first-class} citizens: functions are values and can be used as such
|
|
\item a haskell program is what happens when \emph{expressions are evaluated}, it's not about executing instructions
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{2.2. What does pure mean?}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.2. What does \textbf{pure} mean?}
|
|
\emph{Referential transparency}, as in:
|
|
\onslide<+->
|
|
\begin{itemize}[<+->]
|
|
\item everything (variables, data structures...) is \emph{immutable}
|
|
\item expressions never have side-effects (remember: mathematical functions)
|
|
\item same input $\mapsto$ same output... \emph{always}!
|
|
\item replace a function with it's (return) value? Yes. What happens in C or java if you do that? Remember \code{void pop();}?
|
|
\end{itemize}
|
|
\onslide<+->
|
|
\vspace{\baselineskip}
|
|
possible benefits?
|
|
\begin{itemize}[<+->]
|
|
\item parallelism
|
|
\item equational reasoning and refactoring
|
|
\item less bugs!
|
|
\end{itemize}
|
|
\onslide<+->
|
|
\vspace{\baselineskip}
|
|
Question: call-by-value? call-by-reference? call-by-need?
|
|
\end{frame}
|
|
|
|
\subsection{2.3. What does lazy mean?}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.3. What does \textbf{lazy} mean?}
|
|
In haskell expressions are not evaluated until their results are actually needed. That has a lot of consequences, a few of them being:
|
|
\onslide<+->
|
|
\begin{itemize}[<+->]
|
|
\item infinite data structures are now possible (recursive and non-recursive)
|
|
\item defining new control structures by just defining a function (since not everything is evaluated... who needs if-then-else anyway?)
|
|
\item important for compositional programming and efficiency
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\subsection{2.4. What does statically typed mean?}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.4. What does \textbf{statically typed} mean?}
|
|
Every haskell expression has a type and types are always checked at \emph{compile-time}. Programs with errors will not compile and definitely not run.\\
|
|
\vspace{\baselineskip}
|
|
It is possible to simulate dynamic types however, i.e. types which may be converted to the type you need them in, following rigid rules. In the end, they are still statically type-checked (as in: the compiler always knows what's going on).
|
|
\end{frame}
|
|
|
|
\subsection{2.5. Summary}
|
|
|
|
\begin{frame}
|
|
\frametitle{2.5. What is haskell again?}
|
|
Let's reiterate. Haskell is:
|
|
\begin{itemize}
|
|
\item functional
|
|
\item pure
|
|
\item lazy
|
|
\item statically typed (and truly type-safe)
|
|
\item even garbage collected
|
|
\item the world's finest imperative language (what??)
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{3. How to think haskell?}
|
|
|
|
\begin{frame}
|
|
\frametitle{3. How to think haskell?}
|
|
\begin{itemize}[<+->]
|
|
\item forget about imperative, procedural, OOP; forget about any programming language
|
|
\item think in types!
|
|
\begin{itemize}[<+->]
|
|
\item don't be afraid of type errors
|
|
\item let the type-checker do the work for you (does this function do what I think it does?)
|
|
\item understand functions just by looking at their type signature?
|
|
\end{itemize}
|
|
\item think abstract!
|
|
\begin{itemize}[<+->]
|
|
\item don't repeat yourself!
|
|
\item "develop a solution space, rather than an individual solution" -- Ralf Hinze
|
|
\item "imagine a graph, rather than a single path" -- Ralf Hinze
|
|
\item "first solve a more general problem, then extract the interesting bits and pieces by transforming the general program into more specialised ones" -- Ralf Hinze
|
|
\end{itemize}
|
|
\item solve atomic parts of general problems and combine them into greater solutions
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{4. Declarations}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{4. Declarations}
|
|
Let's go!
|
|
\begin{haskellcode}
|
|
x :: Int
|
|
x = 3
|
|
|
|
-- how about this?
|
|
x = 5
|
|
|
|
-- Int vs Integer
|
|
n :: Integer
|
|
n = 12345678909876543219873409823349873498723498
|
|
|
|
d :: Double
|
|
d = 5.0
|
|
|
|
c :: Char
|
|
c = 'k'
|
|
|
|
s :: String
|
|
s = "Hello, world?"
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\section{5. Arithmetic and co.}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{5. Arithmetic and co.}
|
|
GHCi:
|
|
\begin{haskellcode}
|
|
> 3 + 5
|
|
> (3 :: Integer) + (5 :: Int)
|
|
> 6 * 5.0
|
|
> "Hello" ++ " world"
|
|
> "Haskell" > "C++"
|
|
> True && False
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\section{6. Functions and control structures}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{6. Functions and control structures}
|
|
Let's make our first function. We want something like the following mathematical function\\
|
|
$f(x) = x * x$\\
|
|
\vspace{\baselineskip}
|
|
How could the haskell code look like?
|
|
\pause
|
|
Almost the same:
|
|
\begin{haskellcode}
|
|
f x = x * x
|
|
\end{haskellcode}
|
|
\vspace{\baselineskip}
|
|
GHCi...\\
|
|
\pause
|
|
\vspace{\baselineskip}
|
|
What is a possible type signature for this function?
|
|
\begin{haskellcode}
|
|
f :: Int -> Int
|
|
f x = x * x
|
|
\end{haskellcode}
|
|
So the function gets an Int and returns an Int. Don't get confused by "\verb|->|". Just think of it as a symbol for separating input and output.
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{6. Functions and control structures (ctn.)}
|
|
In haskell we often use \textbf{pattern matching}. That means we define a function multiple times, but e.g. for different values of its input arguments. Let's see:
|
|
\pause
|
|
\vspace{\baselineskip}
|
|
\begin{haskellcode}
|
|
isZero :: Int -> Bool
|
|
isZero 0 = True
|
|
isZero x = False
|
|
\end{haskellcode}
|
|
\vspace{\baselineskip}
|
|
So if we pass it 0, we get True. If we do not pass 0, we get False and the value we passed gets basically ignored.\\
|
|
\vspace{\baselineskip}
|
|
What might happen if we remove the second or the third line? What is a \textbf{partial function} and a \textbf{total function}?
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{6. Functions and control structures (ctn.)}
|
|
How about \emph{recursion}? Let's define the modulo of any \emph{Int} to \emph{2}.
|
|
\pause
|
|
\vspace{\baselineskip}
|
|
\begin{haskellcode}
|
|
mod2 :: Int -> Int
|
|
mod2 x
|
|
| x - 2 == 0 = 0
|
|
| x - 2 < 0 = x
|
|
| otherwise = mod2 (x - 2)
|
|
\end{haskellcode}
|
|
These \verb#|# things above are called \textbf{guards} and are similar to \emph{pattern matching}. They are processed in order. If the condition on the left side of the equation is true, then it returns what stands on the right side of the equation. If it's false, then it processes the next line.\\ \code{otherwise} on the last line is just defined as \code{True}, to make these constructs easier to read and catch all other cases of input.
|
|
\end{frame}
|
|
|
|
\section{7. Pairs/Tuples}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{7. Pairs/Tuples}
|
|
Defining a pair is easy.
|
|
\begin{haskellcode}
|
|
p :: (Int, Char) -- this is the type
|
|
p = (2, 'y') -- this is how we construct the pair
|
|
|
|
-- pattern matching against pairs
|
|
sumPair :: (Int, Int) -> Int
|
|
sumPair (x, y) = x + y
|
|
\end{haskellcode}
|
|
\pause
|
|
Note: we use \code{(x, y)} notation for both the type and the definition! Those are still two different things. We can also have triples, quadruples etc.
|
|
\end{frame}
|
|
|
|
\section{8. Lists}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{8. Lists}
|
|
The list is probably the most basic data structure in Haskell. Like the array in C. It is a singly-linked list and is very lazy. The compiler has numerous ways to optimize lists, so don't be afraid to use them, even for huge things.
|
|
\pause
|
|
We build lists by using either the \code{[]} notation:
|
|
\begin{haskellcode}
|
|
list1 :: [Integer]
|
|
list1 = [1, 2]
|
|
\end{haskellcode}
|
|
\pause
|
|
or by using the \emph{cons} operator \code{(:)} which takes an element and a list and produces a new list with the element prepended to the front.
|
|
\begin{haskellcode}
|
|
emptyList = []
|
|
|
|
list2 = 1 : []
|
|
|
|
-- is this really a list?
|
|
list3 = [1, 2] == 1 : 2 : []
|
|
\end{haskellcode}
|
|
\pause
|
|
How about something more interesting:
|
|
\begin{haskellcode}
|
|
infiniteList = [1..]
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{8. Lists (ctn.)}
|
|
Let's check on a few very common list operations:
|
|
\begin{haskellcode}
|
|
> [1, 2] ++ [4, 5] -- append two lists
|
|
> head [1, 2, 3] -- first element
|
|
> tail [1, 2, 3] -- everything after the head
|
|
> reverse [1, 2, 3] -- reverse a list
|
|
> take 2 [1, 2, 3] -- take the first two elements
|
|
> drop 2 [1, 2, 3] -- drop the first two elements
|
|
> sum [1, 2, 3]
|
|
> elem 7 [1, 2, 3] -- is there a 7 in the list?
|
|
\end{haskellcode}
|
|
\pause
|
|
A String in haskell is just a list of Chars!
|
|
\begin{haskellcode}
|
|
> ['a', 'b', 'c']
|
|
> 'a' : []
|
|
> head "abc"
|
|
> 'a' ++ 'c'
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{8. Lists (ctn.)}
|
|
Again, we can do pattern matching on lists.
|
|
\begin{haskellcode}
|
|
listLen :: [Integer] -> Integer
|
|
listLen [] = 0
|
|
listLen (x:xs) = 1 + listLen xs
|
|
\end{haskellcode}
|
|
\pause
|
|
We can also nest pattern matching:
|
|
\begin{haskellcode}
|
|
sumEveryTwo :: [Integer] -> [Integer]
|
|
sumEveryTwo [] = 0
|
|
sumEveryTwo (x:[]) = [x]
|
|
sumEveryTwo (x:(y:zs)) = (x + y) : sumEveryTwo zs
|
|
\end{haskellcode}
|
|
Note that \code{(x:(y:zs))} may also be written as \code{(x:y:zs)}.
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{8. Lists (ctn.)}
|
|
Haskell also supports \textbf{list comprehension} which is basically syntactic sugar for what we already know from maths.\\
|
|
Let's define a set that contains the first ten even natural numbers:\\
|
|
\pause
|
|
$S = \{2 \times x\ |\ x \in \mathbb{N},\ x \leq 10\}$\\
|
|
\vspace{\baselineskip}
|
|
\pause
|
|
How does this look in haskell?
|
|
\pause
|
|
\begin{haskellcode}
|
|
> [x*2 | x <- [1..10]]
|
|
\end{haskellcode}
|
|
\pause
|
|
Now let's say we want all numbers between 50 and 100 that have the remainder 0 when divided by 12:
|
|
\pause
|
|
\begin{haskellcode}
|
|
> [x | x <- [50..100], mod x 12 == 0]
|
|
\end{haskellcode}
|
|
\code{x <- [50..100]} is the binding, while \code{mod x 12 == 0} is the predicate, separated by a comma. We can have multiple predicates.
|
|
\end{frame}
|
|
|
|
\section{9. Algebraic Data Types}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types}
|
|
Of course we can also define our own data types in haskell. One very common type is the \emph{enumeration}. For example, we could define a data type for the Week:
|
|
\begin{haskellcode}
|
|
data WeekDay = Monday
|
|
| Tuesday
|
|
| Thursday
|
|
| Wednesday
|
|
| Friday
|
|
| Saturday
|
|
| Sunday
|
|
\end{haskellcode}
|
|
This declares the new data type \code{WeekDay} with 7 \emph{constructors}. That means \code{Monday}, \code{Tuesday} etc. are all values of the type \code{WeekDay}.
|
|
\pause
|
|
\\
|
|
We could now define a whole week, by creating a list:
|
|
\pause
|
|
\begin{haskellcode}
|
|
week :: [WeekDay]
|
|
week = [Monday, Tuesday, Thursday, Wednesday
|
|
, Friday, Saturday, Sunday]
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
And we can again \emph{pattern match} on our \code{WeekDay} type. Let's find out if a given day is a Monday:
|
|
\pause
|
|
\begin{haskellcode}
|
|
isMonday :: WeekDay -> Bool
|
|
isMonday Monday = True
|
|
isMonday x = False
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
But we can do more than enumerations. How about we do some error handling? Let's say we want a function to return an \code{Int}, but in case something went horribly wrong, we don't just want to return a 0 or some magic number, but a proper error message. Here we go:
|
|
\pause
|
|
\begin{haskellcode}
|
|
data MaybeInt = NoError Int
|
|
| Error String
|
|
\end{haskellcode}
|
|
\pause
|
|
So constructors are just \emph{functions}! And they can have arguments, just like functions. Let's check their types:
|
|
\begin{haskellcode}
|
|
> :t NoError
|
|
NoError :: Int -> MaybeInt
|
|
> :t Error
|
|
Error :: String -> MaybeInt
|
|
\end{haskellcode}
|
|
\pause
|
|
And now we can do sanity checks:
|
|
\begin{haskellcode}
|
|
calcSomething :: Int -> MaybeInt
|
|
calcSomething x
|
|
| x < 100 = NoError (x * 5)
|
|
| otherwise = Error "Int out of range!"
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
And pattern match on it as well:
|
|
\begin{haskellcode}
|
|
addIntToList :: MaybeInt -> [Int]
|
|
addIntToList (NoError x) = [x]
|
|
addIntToList (Error str) = []
|
|
\end{haskellcode}
|
|
So if we got an error, we just return an empty list, otherwise we return a list with the \code{Int} as its only element.
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
Let's define something more complex. How about a tree?
|
|
\pause
|
|
\begin{haskellcode}
|
|
data Tree = Leaf Char
|
|
| Node Tree Int Tree
|
|
\end{haskellcode}
|
|
Uh... that looks mean. Let's examine this.\\
|
|
\pause
|
|
We have:
|
|
\begin{itemize}[<+->]
|
|
\item defined a data type \code{Tree}
|
|
\item a constructor \code{Leaf} of type \code{Tree} with one arguments of type \code{Char}
|
|
\item a constructor \code{Node} of type \code{Tree} with 3 arguments
|
|
\begin{itemize}[<+->]
|
|
\item \code{Tree}
|
|
\item \code{Int}
|
|
\item \code{Tree}
|
|
\end{itemize}
|
|
\end{itemize}
|
|
\onslide<+->
|
|
That means: a \code{Tree} can either be a \code{Leaf} or an internal \code{Node} with two sub-trees. If we want to create a \code{Leaf}, we have to pass the constructor a \code{Char}. If we want to create a \code{Node}, we have to pass 3 arguments, in order: another \code{Tree}, an \code{Int} and yet another \code{Tree}.\\
|
|
So we can save information in the leafs (\code{Char}) and in the internal nodes (\code{Int}).\\
|
|
This is just an example. There are endless more ways of trees.
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
Let's build our tree:
|
|
\begin{haskellcode}
|
|
tree :: Tree
|
|
tree = Node
|
|
(Leaf 'x')
|
|
1
|
|
(Node
|
|
(Leaf 'y')
|
|
2
|
|
(Leaf 'z')
|
|
)
|
|
\end{haskellcode}
|
|
See board...
|
|
\end{frame}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{9. Algebraic Data Types (ctn.)}
|
|
So if we want to generalize it, an algebraic data type has one or more \textbf{constructors}, and each of them can have zero or more arguments. E.g.:
|
|
\begin{haskellcode}
|
|
data AlgDataType = Constr1 Type11 Type12
|
|
| Constr2 Type21
|
|
| Constr3 Type31 Type32 Type33
|
|
| Constr4
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\section{10. Questions so far?}
|
|
|
|
\begin{frame}
|
|
\frametitle{10. Questions so far?}
|
|
\begin{itemize}
|
|
\item How do functions with multiple parameters look like?
|
|
\item ...
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{11. Common misconceptions}
|
|
|
|
\begin{frame}
|
|
\frametitle{11. Common misconceptions}
|
|
Now that we know the basics, let's clear up some common misconceptions about haskell.
|
|
\begin{itemize}[<+->]
|
|
\item haskell is only a language for university professors
|
|
\item haskell is not used in real world, see \url{https://wiki.haskell.org/Haskell_in_industry}
|
|
\begin{itemize}
|
|
\item Microsoft
|
|
\item NVIDIA
|
|
\item facebook
|
|
\item Google
|
|
\item Intel
|
|
\item AT\Q{&}T
|
|
\end{itemize}
|
|
\item you cannot model states in haskell
|
|
\item you cannot write larger programs in haskell
|
|
\item you cannot write useful programs in haskell
|
|
\item you cannot implement imperative algorithms
|
|
\item you cannot do concurrency, cryptography, web development, ... in haskell
|
|
\end{itemize}
|
|
\onslide<+->
|
|
You can!
|
|
\end{frame}
|
|
|
|
\section{12. Difficulties}
|
|
|
|
\begin{frame}
|
|
\frametitle{12. Difficulties}
|
|
Haskell is very powerful and can be used for pretty much anything. However, there are difficulties in any language. Let's name a few for haskell:
|
|
\begin{itemize}[<+->]
|
|
\item intellectual complexity? New way of thinking?
|
|
\item although you rarely need it in haskell, debugging can be difficult at times
|
|
\item because the type system is extremely powerful/complex, type error messages can be very confusing and don't always show the error you expected
|
|
\item no premium-like IDE with every possible feature (yet)
|
|
\item dynamic linking is sort of WIP yet, lots of ABI breakage
|
|
\item because most of the world thinks in imperative style languages, it's often difficult to find pseudo-code for functional style languages, so you end up reverse-engineering algorithms
|
|
\item some problems that are trivial in imperative languages, can be very difficult to solve in idiomatic haskell and vice versa
|
|
\item practical cryptography is possible, but a difficult topic in haskell, see \url{https://mail.haskell.org/pipermail/haskell-cafe/2015-February/118059.html}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{13. Toolchain}
|
|
|
|
\begin{frame}
|
|
\frametitle{13. Toolchain}
|
|
How to get started? You need:
|
|
\begin{itemize}
|
|
\item \textbf{GHC}: this is the Haskell compiler
|
|
\item \textbf{GHCi}: this an interactive environment of GHC, similar to the interactive ruby shell \emph{irb}
|
|
\item \textbf{The Haskell Platform}: a collection including GHC, GHCi and basic libraries
|
|
\end{itemize}
|
|
Go to \url{https://www.haskell.org/platform}\\
|
|
For haskell IDEs, see \url{https://wiki.haskell.org/IDEs}
|
|
\end{frame}
|
|
|
|
|
|
\section{14. What you should know}
|
|
|
|
\begin{frame}
|
|
\frametitle{14. What you should know now}
|
|
\begin{itemize}
|
|
\item what haskell is
|
|
\item how you write haskell functions
|
|
\item how you handle lists and pairs
|
|
\item how you do pattern matching
|
|
\item how you create your own data types
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{15. Questions for you}
|
|
|
|
\begin{frame}[fragile]
|
|
\frametitle{15. Questions for you}
|
|
\begin{itemize}
|
|
\item What are side effects?
|
|
\item What is referential transparency?
|
|
\item Can you have referential transparency with side effects?
|
|
\item What does the output of a haskell function depend on?
|
|
\item What is laziness?
|
|
\item When are types checked in haskell?
|
|
\end{itemize}
|
|
\vspace{\baselineskip}
|
|
Does this compile? If not, fix it. Is this a total function?
|
|
\begin{haskellcode}
|
|
data IntOrDouble = MkDouble Double
|
|
| MkInt Int
|
|
|
|
f :: Int -> IntOrDouble
|
|
f 0 = 0.5
|
|
\end{haskellcode}
|
|
\end{frame}
|
|
|
|
\section{16. Links}
|
|
|
|
\begin{frame}
|
|
\frametitle{16. Further reading and useful links}
|
|
\begin{itemize}
|
|
\item the most popular haskell course from Brent Yorgey:\\ \url{https://www.seas.upenn.edu/~cis194/fall14/spring13/lectures.html}
|
|
\item very verbose and enthusiastic haskell book, good for reading once:\\ \url{http://learnyouahaskell.com}
|
|
\item collection of websites teaching haskell:\\ \url{https://github.com/bitemyapp/learnhaskell}
|
|
\item haskell programming tips (and wiki):\\ \url{https://wiki.haskell.org/Haskell_programming_tips}
|
|
\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}
|
|
|
|
\section{17. Sources}
|
|
|
|
\begin{frame}
|
|
\frametitle{17. 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}
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\end{document} |