![](\"https://raw.githubusercontent.com/rober-m/haskell-bootcamp/main/images/input-output.svg\"/)
"
+ },
+ "vscode": {
+ "interpreter": {
+ "hash": "31f2aee4e71d21fbe5cf8b01ff0e069b9275f58929596ceb00d14d90e3e16cd6"
+ }
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/ES-translation/Tarea/Tarea03/Tarea03.hs b/ES-translation/Tarea/Tarea03/Tarea03.hs
new file mode 100644
index 00000000..5a7b2a03
--- /dev/null
+++ b/ES-translation/Tarea/Tarea03/Tarea03.hs
@@ -0,0 +1,29 @@
+-- Pregunta 1
+-- Escribe una función que chequea si el consumo eléctrico mensual de un dispositivo es mayor, igual o menor que un máximo permitido y
+-- retornar un mensaje acorde.
+-- La función debe recibir el consumo eléctrico por hora del dispositivo, cantidad de horas de uso diarias y el máximo consumo mensual permitido.
+-- Uso mensual = consumo (kW) * horas de uso diario (h) * 30 días.
+
+
+-- Pregunta 2
+-- Preludio:
+-- Nosotros utilizamos la función `show :: a -> String` para transformar cualquier tipo en String.
+-- Entonces `show 3` producirá `"3"` y `show (3 > 2)` producirá `"True"`.
+
+-- En la función previa, retornar el exceso/ahorro de consumo como parte del mensaje.
+
+
+-- Pregunta 3
+-- Escribe una función que muestre las ventajas del uso de expresiones que dividen expresiones grandes en expresiones más chicas
+-- Luego, compartela con otros estudiantes en Canvas.
+
+
+-- Pregunta 4
+-- Escribe una función que toma dos números y retorna su cociente tal que no sea mayor que 1.
+-- Retornar el número como un string (cadena de caracteres), y en caso que el divisor sea 0, retornar un mensaje indicando porque la división no es posible.
+-- Para implementar esta función utilizar guardas y sentencias if-then-else.
+
+
+-- Pregunta 5
+-- Escribe una fución que toma dos númerso y calcula la suma de sus raíces cuadradas, para el producto y el cociente de dichos números.
+-- Escribe la función utilizando un bloque where, adentro de una expresión let y una expresión let adentro de un bloque where.
diff --git a/ES-translation/Tarea/Tarea04/Tarea04.hs b/ES-translation/Tarea/Tarea04/Tarea04.hs
new file mode 100644
index 00000000..e5f41e89
--- /dev/null
+++ b/ES-translation/Tarea/Tarea04/Tarea04.hs
@@ -0,0 +1,29 @@
+-- Pregunta 1
+-- Consideremos los valores anidados indicados más abajo. ¿Cómo obtendrías el valor 4 utilizando en la función únicamente concordancia de patrones?
+
+anidado :: [([Int], [Int])]
+anidado = [([1,2],[3,4]), ([5,6],[7,8])]
+
+-- Pregunta 2
+-- Escribe una función que toma una lista de elementos de cualquier tipo y, si la lista tiene 3 o más elementos, los remueve.
+-- En caso contrario no hace nada.
+-- Escribela dos veces, una con múltiples definiciones de funciones y otra con expresiones case.
+
+
+-- Pregunta 3
+-- Crea una función que toma una tupla de 3 elemnentos (todos de tipo Integer) y los suma
+
+
+-- Pregunta 4
+-- Implementa una función que retorna True si una lista es vacía y False en caso contrario.
+
+
+-- Pregunta 5
+-- Escribe una implementación de la función tail utilizando concordancia de patrones.
+-- Pero en lugar de fallar en el caso de la lista vacía, retornar una lista vacía.
+
+
+-- Pregunta 6
+-- Escribe una expresión case contenida en una función que toma un Int y le suma uno (1) en el caso de que sea impar.
+-- En caso contrario no hace nada. (Utilizar la función `even` para chequear si el parámentro de entrada es impar).
+
diff --git a/ES-translation/Tarea/Tarea05/Tarea05.hs b/ES-translation/Tarea/Tarea05/Tarea05.hs
new file mode 100644
index 00000000..2e72f351
--- /dev/null
+++ b/ES-translation/Tarea/Tarea05/Tarea05.hs
@@ -0,0 +1,27 @@
+-- Crea una función de orden superior que reciba 3 parámetros: Una función y los dos parámentros de dicha función, e
+-- invertir el orden de los parámetros.
+-- Por ejemplo: `(/) 6 2` retorna `3`. Pero: `flip' (/) 6 2` retorna `0.3333333333`
+
+
+-- Crea la función `uncurry'` que convierte una función currificada en una función sobre pares.
+-- O sea, esto: `(+) 1 2` que retorna `3` puede ser escrito como `uncurry' (+) (1,2)` (con los dos argumentos adentro del par).
+
+
+-- Crear la función `curry` que convierte una función no currificada en una currificada.
+-- O sea, esto: `fst (1,2)` que retorna `1` puede ser escrito como `curry' fst 1 2` (con la tupla convertida en dos argumentos diferentes).
+
+
+-- Utiliza funciones de orden superior, aplicación parcial y estilo de punto-libre para crear una fucnión que chequea si una palabra contiene una letra mayúscula.
+-- Comienza utilizando simplemente una función de orden superior y construye desde allí.
+
+
+-- Crea la función `contar`que recibe un equipo ("Rojo", "Azul", o "Verde") y devuelve la cantidad de votos que cada equipo tiene en `votos`.
+
+votos :: [String]
+votos = ["Rojo", "Azul", "Verde", "Azul", "Azul", "Rojo"]
+
+
+-- Crea una función de una línea, que filtre `autos` por marca e indique si queda alguno disponible.
+
+cars :: [(String,Int)]
+cars = [("Toyota",0), ("Nissan",3), ("Ford",1)]
diff --git a/Homework/Homework03/Homework03.hs b/Homework/Homework03/Homework03.hs
index 41035315..6c681882 100644
--- a/Homework/Homework03/Homework03.hs
+++ b/Homework/Homework03/Homework03.hs
@@ -25,6 +25,6 @@
-- Question 5
--- Write a function that takes in two numbers and calculates the sum of squares for the product and quotient
+-- Write a function that takes in two numbers and calculates the sum of square roots for the product and quotient
-- of those numbers. Write the function such that you use a where block inside a let expression and a
-- let expression inside a where block.
diff --git a/Homework/Homework07/Homework07.hs b/Homework/Homework07/Homework07.hs
index a52c0de9..69c49b90 100644
--- a/Homework/Homework07/Homework07.hs
+++ b/Homework/Homework07/Homework07.hs
@@ -12,9 +12,13 @@
-- Question 4
--- Add type signatures to the functions below and use type variables and type classes.
+-- Add the most general type signatures possible to the functions below.
-- Then uncomment the functions and try to compile.
+--f1 x y z = show (x / y) ++ z
+
+--f2 x = if x == maxBound then minBound else succ x
+
-- Question 5
-- Investigate the numeric type classes to figure out which behaviors they provide to change between numeric types.
diff --git a/Homework/Homework09/1-Maze.hs b/Homework/Homework09/1-Maze.hs
new file mode 100644
index 00000000..a66c9dda
--- /dev/null
+++ b/Homework/Homework09/1-Maze.hs
@@ -0,0 +1,55 @@
+{-
+
+**************************** IMPORTANT ****************************
+
+This week is a two-step homework. First, you have to solve the
+"Maze" challenge, and then the "Forest" challenge. The challenges
+are in two separate files in both the homework and solution, so
+you can check the solution for the first "Maze" challenge without
+spoilers of the "Forest" one. Make sure to check the solution for
+"Maze" (and only "Maze," I see you 🥸👀) before starting with the
+"Forest" challenge!
+
+*******************************************************************
+
+Today, you'll build the simplest and most basic game imaginable.
+It'll be a maze game where the player has to write a list of moves, and the game will perform them
+and tell the player where it ends up. Then, the player can change the moves and check again until it
+finds the exit.
+
+To play the game, the player will open GHCi, load this file, and run a "solveMaze" function that
+takes a maze and a list of moves and returns a String with the resulting state.
+
+It should look like this:
+
+*Main> solveMaze testMaze []
+"You're still inside the maze. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+*Main> solveMaze testMaze [GoLeft]
+"You've hit a wall!"
+*Main> solveMaze testMaze [GoForward]
+"You're still inside the maze. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+*Main> solveMaze testMaze [GoForward, GoRight]
+"You've hit a wall!"
+*Main> solveMaze testMaze [GoForward, GoLeft]
+"YOU'VE FOUND THE EXIT!!"
+
+How are you going to achieve this? You can try it on your own, but here you have a
+step-by-step just in case:
+
+1. Write two data types. One for the moves (Move) you can make, and another for the maze (Maze).
+(Use the example above to figure them out.)
+
+2. Write a function called "move" that takes a maze and a move and returns the maze after the move.
+
+3. Write a "testMaze" value of type "Maze" and test the "move" function in GHCi.
+
+4. Write the "solveMaze" function that will take a maze and a list of moves and returns the maze
+after making those moves.
+
+5. If you test the "solveMaze" function, you'll see that each time you try to solve the maze,
+it'll print the whole maze for the player to see. To avoid that, write a "showCurrentChoice" function
+that takes a maze and returns a different string depending on if you hit a wall, found the exit, or
+still need to make another choice.
+
+6. Adapt adapt "solveMaze" function to use "showCurrentChoice" and play with your new game using GHCi! :D
+-}
diff --git a/Homework/Homework09/2-Forest.hs b/Homework/Homework09/2-Forest.hs
new file mode 100644
index 00000000..c6ee2482
--- /dev/null
+++ b/Homework/Homework09/2-Forest.hs
@@ -0,0 +1,44 @@
+{-
+
+**************************** IMPORTANT ****************************
+
+Solve this homework after completing and checking the "Maze" one.
+
+*******************************************************************
+
+We're going to build on top of the "Maze" challenge by coding a similar
+but a bit more complicated game.
+
+It works the same as the "Maze" game, with the difference that the player
+is now in a forest. Because we're in a forest, there are no walls. And,
+if you walk long enough, you're guaranteed to find the exit.
+
+So, what's the challenge in playing this game? The challenge lies in that
+now we have "stamina." Stamina is a number (we start with 10). And, each
+time the player makes a move, its stamina gets reduced by the amount of work
+needed to cross the current trail (represented by a number contained in the
+value constructor).
+
+The data types and functions are pretty much the same, with a few caveats:
+
+- We don't have walls.
+- We don't want to choose a specific numeric type, but we want to make sure
+we can do basic numeric operations regardless of the type we pass to the functions.
+- Because now we have to keep track of the player's stamina, we'll need to
+move it around with our current forest. This would be an awesome use case
+for monads, but because we don't know how to use them yet, a "(stamina, forest)"
+pair will have to do.
+
+Using GHCi, like the "Maze" game, this game should look like this:
+
+*Main> solveForest testForest []
+"You have 10 stamina, and you're still inside the Forest. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+*Main> solveForest testForest [GoForward ]
+"You have 7 stamina, and you're still inside the Forest. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+*Main> solveForest testForest [GoForward, GoForward]
+"You have 4 stamina, and you're still inside the Forest. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+*Main> solveForest testForest [GoForward, GoForward, GoLeft ]
+"You ran out of stamina and died -.-!"
+*Main> solveForest testForest [GoForward, GoLeft , GoRight]
+"YOU'VE FOUND THE EXIT!!"
+-}
diff --git a/Homework/Homework10/Homework.hs b/Homework/Homework10/Homework.hs
new file mode 100644
index 00000000..cb3367a2
--- /dev/null
+++ b/Homework/Homework10/Homework.hs
@@ -0,0 +1,60 @@
+{-
+-- Question 1 --
+Continuing with the logistics software of the lesson:
+ 1. After using the `Container` type class for a while, you realize that it might need a few adjustments:
+ - First, write down the `Container` type class and its instances, same as we did in the lesson
+ (try to do it without looking and check at the end or if you get stuck).
+ - Then, add a function called `unwrap` that gives you back the value inside a container.
+ 2. Create an instance for the `MailedBox` data type.
+ - The MailedBox data type represents a box sent through the mail.
+ - The parameter `t` is a tag with a person's identifier
+ - The parameter `d` is the person's details (address,etc).
+ - The parameter `a` is the content of the MailedBox
+-}
+
+data MailedBox t d a = EmptyMailBox t d | MailBoxTo t d a
+
+-- Question 2 --
+-- Create instances for Show, Eq, and Ord for these three data types (use
+-- automatic deriving whenever possible):
+
+data Position = Intern | Junior | Senior | Manager | Chief
+
+data Experience = Programming | Managing | Leading
+
+type Address = String
+
+data Salary = USD Double | EUR Double
+
+data Relationship
+ = Contractor Position Experience Salary Address
+ | Employee Position Experience Salary Address
+
+data Pokemon = Pokemon
+ { pName :: String,
+ pType :: [String],
+ pGeneration :: Int,
+ pPokeDexNum :: Int
+ }
+
+charizard = Pokemon "Charizard" ["Fire", "Flying"] 1 6
+
+venusaur = Pokemon "Venusaur" ["Grass", "Poison"] 1 3
+
+-- Question 3 -- EXTRA CREDITS
+-- Uncomment the next code and make it work (Google what you don't know).
+
+-- -- Team memeber experience in years
+-- newtype Exp = Exp Double
+--
+-- -- Team memeber data
+-- type TeamMember = (String, Exp)
+--
+-- -- List of memeber of the team
+-- team :: [TeamMember]
+-- team = [("John", Exp 5), ("Rick", Exp 2), ("Mary", Exp 6)]
+--
+-- -- Function to check the combined experience of the team
+-- -- This function applied to `team` using GHCi should work
+-- combineExp :: [TeamMember] -> Exp
+-- combineExp = foldr ((+) . snd) 0
diff --git a/Homework/Homework11/Homework.hs b/Homework/Homework11/Homework.hs
new file mode 100644
index 00000000..77c4d7df
--- /dev/null
+++ b/Homework/Homework11/Homework.hs
@@ -0,0 +1,105 @@
+import Data.List
+import System.CPUTime (getCPUTime)
+import System.Directory (doesFileExist, listDirectory)
+import Text.XHtml (thead)
+
+{-
+We imported some functions that you'll need to complete the homework.
+FilePath is just a synonym for String. Although, make sure to follow the standard path
+representation when using them (https://en.wikipedia.org/wiki/Path_(computing).
+getCPUTime :: IO Integer
+doesFileExist :: FilePath -> IO Bool
+listDirectory :: FilePath -> IO [FilePath]
+You can hover over the functions to know what they do.
+-}
+
+{-
+-- Question 1 --
+Define an IO action that counts the number of all enteries in the current directory
+and prints it to the terminal inside a string message.
+(hidden files are not included)
+-}
+
+-- listFiles :: IO ()
+
+{-
+-- Question 2 --
+Write an IO action that asks the user to type something, then writes the message
+to a file called msg.txt, and after that, it reads the text from the msg.txt
+file and prints it back. Use the writeFile and readFile functions.
+-}
+
+-- createMsg :: IO ()
+
+
+{-
+-- Context for Questions 3 and 4 --
+In cryptography, prime numbers (positive integers only divisible by themselves and 1) play a fundamental
+role in providing unbreakable mathematical structures. These structures, in turn, are leveraged to
+establish secure encryption.
+But, generating primes is a computational straining problem, as we will measure in the following exercise.
+This is because, to know whether a number is a prime number, you first need to know all the previous primes
+and then check that they are not a divisor of this number. So, this problem gets bigger and bigger!
+Our lead cryptographer provided us with 3 different algorithms (primes1, primes2, and primes3). All three
+correctly produce a list of all the prime numbers until a limit (that we provide as a parameter).
+Our job is not to understand these algorithms but to measure which is the fastest and print the largest
+prime number below our limit. Do it step by step, starting with question 3.
+-}
+
+primes1 :: Integer -> [Integer]
+primes1 m = sieve [2 .. m]
+ where
+ sieve [] = []
+ sieve (p : xs) = p : sieve [x | x <- xs, x `mod` p > 0]
+
+primes2 :: Integer -> [Integer]
+primes2 m = sieve [2 .. m]
+ where
+ sieve (x : xs) = x : sieve (xs \\ [x, x + x .. m])
+ sieve [] = []
+
+primes3 :: Integer -> [Integer]
+primes3 m = turner [2 .. m]
+ where
+ turner [] = []
+ turner (p : xs) = p : turner [x | x <- xs, x < p * p || rem x p /= 0]
+
+{-
+-- Question 3 --
+Define an IO action that takes an IO action as input and calculates the time it takes to execute.
+Use the getCPUTime :: IO Integer function to get the CPU time before and after the IO action.
+The CPU time here is given in picoseconds (which is 1/1000000000000th of a second).
+-}
+
+-- timeIO :: IO a -> IO ()
+
+
+{-
+-- Question 4 --
+Write an action that retrieves a value from the standard input, parses it as an integer,
+and compares the time all three algorithms take to produce the largest prime before the
+limit. Print the number and time to the standard output.
+-}
+
+-- benchmark :: IO ()
+
+{-
+ -- Question 5 -- EXTRA CREDITS -- (In case the previous ones were too easy)
+Write a program that prints the directory tree structure from the current folder.
+Below you can see an example output of how such a structure looks like:
+.
+├── foo1.hs
+├── foo2.hs
+├── bar1
+ ├── bar2
+ ├── foo3.hs
+ ├── foo4.hs
+ └── bar3
+ └── foo5.hs
+└── bar5
+ ├── bar6
+ ├── foo6.hs
+ └── foo7.hs
+HINT: You can use the function doesFileExist, which takes in a FilePath and returns
+True if the argument file exists and is not a directory, and False otherwise.
+-}
diff --git a/Homework/Homework14/ForestGameHWSolution/CHANGELOG.md b/Homework/Homework14/ForestGameHWSolution/CHANGELOG.md
new file mode 100644
index 00000000..a76db143
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/CHANGELOG.md
@@ -0,0 +1,5 @@
+# Revision history for ForestModule
+
+## 0.1.0.0 -- YYYY-mm-dd
+
+* First version. Released on an unsuspecting world.
diff --git a/Homework/Homework14/ForestGameHWSolution/ForestGameHWSolution.cabal b/Homework/Homework14/ForestGameHWSolution/ForestGameHWSolution.cabal
new file mode 100644
index 00000000..bd0c923f
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/ForestGameHWSolution.cabal
@@ -0,0 +1,21 @@
+cabal-version: 3.0
+name: ForestGame
+version: 0.1.0.0
+license: MIT
+license-file: LICENSE
+author: Robertino Martinez
+maintainer: robertino.martinez@iohk.io
+category: Game
+build-type: Simple
+extra-doc-files: CHANGELOG.md
+
+
+executable ForestModule
+ import: warnings
+ main-is: Main.hs
+ other-modules: Forest.Level1
+ , User.Actions.Move
+ build-depends: base ^>=4.16.4.0
+ , random
+ hs-source-dirs: app
+ default-language: Haskell2010
diff --git a/Homework/Homework14/ForestGameHWSolution/LICENSE b/Homework/Homework14/ForestGameHWSolution/LICENSE
new file mode 100644
index 00000000..ecfc812d
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/LICENSE
@@ -0,0 +1,20 @@
+Copyright (c) 2023 Robertino Martinez
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/Homework/Homework14/ForestGameHWSolution/app/Main.hs b/Homework/Homework14/ForestGameHWSolution/app/Main.hs
new file mode 100644
index 00000000..4084cb01
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/app/Main.hs
@@ -0,0 +1,28 @@
+{-# LANGUAGE TypeApplications #-}
+
+module Main where
+
+import Forest.Level1 (Forest (..), level1forest)
+import System.Random (randomRIO)
+import User.Actions.Move (AvailableMoves, move)
+import User.Actions.Battle (battle)
+
+main :: IO ()
+main = do
+ startingStamina <- randomRIO @Int (10_000, 20_000)
+ putStrLn "\nYou're traped in a Forest, try to scape! Remember that you loose stamina with each step you take."
+ gameLoop (startingStamina, level1forest)
+ where
+ gameLoop (_, FoundExit) = putStrLn "YOU'VE FOUND THE EXIT!!"
+ gameLoop (s, _) | s <= 0 = putStrLn "You ran out of stamina and died -.-!"
+ gameLoop (s, forest) = do
+ let continueLoop = do
+ putStrLn $ "\nYou have " ++ show s ++ " stamina, and you're still inside the Forest. Choose a path, brave adventurer: GoLeft, GoRight, or GoForward."
+ selectedMove <- getLine
+ gameLoop $ move (s, forest) (read @AvailableMoves selectedMove)
+ battleDice <- randomRIO @Int (0, 3)
+ case battleDice of
+ 2 -> do
+ r <- battle
+ if r then continueLoop else return ()
+ _ -> continueLoop
\ No newline at end of file
diff --git a/Homework/Homework14/ForestGameHWSolution/src/Forest/Level1.hs b/Homework/Homework14/ForestGameHWSolution/src/Forest/Level1.hs
new file mode 100644
index 00000000..bd68ba8f
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/src/Forest/Level1.hs
@@ -0,0 +1,26 @@
+module Forest.Level1 (Forest (..), level1forest) where
+
+data Forest a = FoundExit | Trail a (Forest a) (Forest a) (Forest a) deriving (Show)
+
+level1forest :: (Num a, Ord a) => Forest a
+level1forest =
+ Trail
+ 3_000
+ ( Trail
+ 7_000
+ (Trail 3_000 FoundExit FoundExit FoundExit)
+ (Trail 4_000 FoundExit FoundExit FoundExit)
+ (Trail 5_000 FoundExit FoundExit FoundExit)
+ )
+ ( Trail
+ 3_000
+ (Trail 3_000 FoundExit FoundExit FoundExit)
+ (Trail 9_000 FoundExit FoundExit FoundExit)
+ (Trail 5_000 FoundExit FoundExit FoundExit)
+ )
+ ( Trail
+ 5_000
+ (Trail 3_000 FoundExit FoundExit FoundExit)
+ (Trail 4_000 FoundExit FoundExit FoundExit)
+ (Trail 1_000 FoundExit FoundExit FoundExit)
+ )
diff --git a/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Battle.hs b/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Battle.hs
new file mode 100644
index 00000000..98e344ed
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Battle.hs
@@ -0,0 +1,12 @@
+{-# LANGUAGE TypeApplications #-}
+{-# LANGUAGE NamedFieldPuns #-}
+{-# LANGUAGE RecordWildCards #-}
+
+module User.Actions.Battle where
+
+data Golem = Golem { gAttack :: Int, gHp :: Int } deriving Show
+data Player = Player { pAttack :: Int, pHp :: Int } deriving (Show)
+data Battle = Fight | RunAway deriving (Show, Read)
+
+battle :: IO Bool
+battle = undefined
\ No newline at end of file
diff --git a/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Move.hs b/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Move.hs
new file mode 100644
index 00000000..83c6981f
--- /dev/null
+++ b/Homework/Homework14/ForestGameHWSolution/src/User/Actions/Move.hs
@@ -0,0 +1,11 @@
+module User.Actions.Move (AvailableMoves (..), move) where
+
+import Forest.Level1 (Forest (..))
+
+data AvailableMoves = GoForward | GoLeft | GoRight deriving (Show, Read)
+
+move :: Num a => (a, Forest a) -> AvailableMoves -> (a, Forest a)
+move (s, FoundExit) _ = (s, FoundExit)
+move (s, Trail a x _ _) GoLeft = (s - a, x)
+move (s, Trail a _ x _) GoForward = (s - a, x)
+move (s, Trail a _ _ x) GoRight = (s - a, x)
\ No newline at end of file
diff --git a/Homework/Homework15/CHANGELOG.md b/Homework/Homework15/CHANGELOG.md
new file mode 100644
index 00000000..4644279b
--- /dev/null
+++ b/Homework/Homework15/CHANGELOG.md
@@ -0,0 +1,5 @@
+# Revision history for Homework15
+
+## 0.1.0.0 -- YYYY-mm-dd
+
+* First version. Released on an unsuspecting world.
diff --git a/Homework/Homework15/Homework15.cabal b/Homework/Homework15/Homework15.cabal
new file mode 100644
index 00000000..f921658d
--- /dev/null
+++ b/Homework/Homework15/Homework15.cabal
@@ -0,0 +1,27 @@
+cabal-version: 3.0
+name: Homework15
+version: 0.1.0.0
+license: MIT
+license-file: LICENSE
+author: Robertino Martinez
+maintainer: robertino.martinez@iohk.io
+build-type: Simple
+extra-doc-files: CHANGELOG.md
+
+common warnings
+ ghc-options: -Wall
+
+executable Homework15A
+ import: warnings
+ main-is: Homework15A.hs
+ build-depends: base ^>=4.16.4.0
+ hs-source-dirs: app
+ default-language: Haskell2010
+
+
+library
+ import: warnings
+ build-depends: base ^>=4.16.4.0
+ hs-source-dirs: src
+ exposed-modules: Homework15B
+ default-language: Haskell2010
diff --git a/Homework/Homework15/LICENSE b/Homework/Homework15/LICENSE
new file mode 100644
index 00000000..ecfc812d
--- /dev/null
+++ b/Homework/Homework15/LICENSE
@@ -0,0 +1,20 @@
+Copyright (c) 2023 Robertino Martinez
+
+Permission is hereby granted, free of charge, to any person obtaining
+a copy of this software and associated documentation files (the
+"Software"), to deal in the Software without restriction, including
+without limitation the rights to use, copy, modify, merge, publish,
+distribute, sublicense, and/or sell copies of the Software, and to
+permit persons to whom the Software is furnished to do so, subject to
+the following conditions:
+
+The above copyright notice and this permission notice shall be included
+in all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
+IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
+CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
+TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
+SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
diff --git a/Homework/Homework15/README.md b/Homework/Homework15/README.md
new file mode 100644
index 00000000..3ed70eb1
--- /dev/null
+++ b/Homework/Homework15/README.md
@@ -0,0 +1,6 @@
+
+## Homework
+
+1. Read the [Data.Maybe](https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Maybe.html) and [Data.Either](https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-Either.html) modules.
+2. Read the [Control.Exception](https://hackage.haskell.org/package/base-4.18.0.0/docs/Control-Exception.html) module skipping the "Asynchronous Exceptions" section.
+3. Solve Homework15A (inside `app` directory) and Homework15B (inside `src`).
\ No newline at end of file
diff --git a/Homework/Homework15/app/Homework15A.hs b/Homework/Homework15/app/Homework15A.hs
new file mode 100644
index 00000000..b6cae1c7
--- /dev/null
+++ b/Homework/Homework15/app/Homework15A.hs
@@ -0,0 +1,58 @@
+module Main where
+
+--------------------------------------------------------------------------------
+--------------------------------------------------------------------------------
+-- IMPORTANT: Read the README.md file before completing the homework.
+--------------------------------------------------------------------------------
+--------------------------------------------------------------------------------
+
+-- This is a CLI application that allows the user to manage a TODO list.
+-- The user can add and remove items from the list and save and load the list
+-- from a file.
+-- It's a working prototype, but it has some bugs. Specifically, it doesn't
+-- handle errors very well. Your mission, should you choose to accept it, is to
+-- fix those bugs and make the application more robust. Hint: Try to interact
+-- with the application in unexpected ways and see what happens! You should be
+-- able to find and fix 3 bugs.
+
+printTodoItem :: (Int, String) -> IO ()
+printTodoItem (n, todo) = putStrLn (show n ++ ": " ++ todo)
+
+prompt :: [String] -> IO ()
+prompt todos = do
+ putStrLn ""
+ putStrLn "Current TODO list:"
+ foldr (\x k -> printTodoItem x >> k) (return ()) (zip [0 ..] todos)
+ command <- getLine
+ interpretCommand command todos
+
+delete :: Int -> [a] -> [a]
+delete 0 (_ : as) = as
+delete _ [] = []
+delete n (a : as) = a : delete (n - 1) as
+
+interpretCommand :: String -> [String] -> IO ()
+interpretCommand cmd todos = case cmd of
+ "q" -> return ()
+ ('+' : ' ' : todo) -> prompt (todo : todos)
+ ('-' : ' ' : num) -> prompt $ delete (read num) todos
+ ('s' : ' ' : fn) ->
+ writeFile fn (show todos)
+ ('l' : ' ' : fn) -> readFile fn >>= prompt . read
+ _ -> do
+ putStrLn ("Invalid command: `" ++ cmd ++ "`")
+ prompt todos
+
+printCommands :: IO ()
+printCommands = do
+ putStrLn "Commands:"
+ putStrLn "+ ![\"Binary](\"../images/BST.png\"/)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "In a Binary Tree:\n",
+ "* Each node can have at most two child nodes\n",
+ "* It has only one root, that is, a node without a parent (node 8, in this case).\n",
+ "* And has only one path to get to any node.\n",
+ "\n",
+ "So, the node of value 3 is the child of node 8 and the parent of nodes 1 and 6. And the only way to get to node 7 is through 8, 3, 6, and 7.\n",
+ "\n",
+ "That's a binary tree. Now, what makes this \"Binary Tree\" a \"Binary Search Tree\" is that the value of each node is greater than all the values under the node's left subtree and smaller than the ones under its right subtree. For example, all the values under node 8's left subtree are smaller than 8, and all the values under node 8's right subtree are larger than 8.\n",
+ "\n",
+ "By knowing this, each time we check the value of a node, and it's not the one we're looking for, we know that if the value is smaller, we have to keep looking on the left subtree, and if it's bigger, we have to keep going on the right subtree. Allowing us to discard all the nodes of the other branch and reducing the size of the problem in half. Same as we did in the dictionary example."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Ok, so how do we translate this to code? Well, Haskell makes it surprisingly easy. "
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 18,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "data Sequence a = EmptyS | Node a (Sequence a) deriving (Show)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "In our `Sequence a` type, we had one case where the node was empty and one when the node had a value and pointed to the rest of the sequence.\n",
+ "\n",
+ "To make a BST, we need virtually the same type, except that now we want them to point to up to two sequences that are now trees. So the data type we need is this one:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 19,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "Node :: forall a. a -> Tree a -> Tree a -> Tree a"
+ ],
+ "text/plain": [
+ "Node :: forall a. a -> Tree a -> Tree a -> Tree a"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "data Tree a = EmptyT | Node a (Tree a) (Tree a) deriving (Show)\n",
+ "\n",
+ ":t Node"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "And that's it! The only difference lies in the `Node` constructor, which now contains a value and two different subtrees. \n",
+ "\n",
+ "Let's plant a few trees:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 20,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- data Tree a = EmptyT | Node a (Tree a) (Tree a) \n",
+ "\n",
+ "emptyTree :: Tree a\n",
+ "emptyTree = EmptyT\n",
+ "\n",
+ "oneLevelTree :: Tree Char\n",
+ "oneLevelTree = Node 'a' EmptyT EmptyT\n",
+ "\n",
+ "twoLevelTree :: Tree Integer\n",
+ "twoLevelTree = Node 8\n",
+ " (Node 3 EmptyT EmptyT)\n",
+ " (Node 10 EmptyT EmptyT)\n",
+ "\n",
+ "threeLevelTree :: Tree Integer -- Almost the same as the tree of the image\n",
+ "threeLevelTree = Node 8\n",
+ " (Node 3\n",
+ " (Node 1 EmptyT EmptyT)\n",
+ " (Node 6 EmptyT EmptyT)\n",
+ " )\n",
+ " (Node 10\n",
+ " EmptyT\n",
+ " (Node 14 EmptyT EmptyT)\n",
+ " )"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Awesome. We have our data type ready to rock! We now need to implement the function to check if an element is inside a tree.\n",
+ "\n",
+ "We start, as always, with the type. The function will take a value of type `a` and a tree of values of type `a`. It will check if the value is inside the tree and return a `Bool` of value `True` if it is and `False` if it isn't. So we can start with a type signature like this one:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "elemTree :: a -> Tree a -> Bool\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Now, because the `Tree` type has two constructors, we know that it's likely we'll need two definitions (one per constructor) as the two cases. One for when the tree is empty, and one for when it's not:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "elemTree :: a -> Tree a -> Bool\n",
+ "elemTree v EmptyT = False\n",
+ "elemTree v (Node x left right) = ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "If the tree is empty, the value we provided is obviously not inside the tree, so we return `False`.\n",
+ "\n",
+ "And what if the tree is not empty? Well, we just pattern-matched the node and have its value right there. Might as well check if it's the one we need:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "elemTree :: (Eq a) => a -> Tree a -> Bool\n",
+ "elemTree v EmptyT = False\n",
+ "elemTree v (Node x left right) = if v == x then True else ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Because we are checking if the value of the first parameter is equal to the value inside the tree, we know the type `a` has to be an instance of the `Eq` type class. So we add that constraint to the signature.\n",
+ "\n",
+ "If it is equal, we return `True` and end of the story. But if it's not, we have to choose the subtree to keep looking. And that depends if the value is bigger or smaller than the one in the node. So we not only have to check if the value is equal but also greater or smaller than the value of the node."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "elemTree :: (Ord a) => a -> Tree a -> Bool\n",
+ "elemTree v EmptyT = False\n",
+ "elemTree v (Node x left right)\n",
+ " | v == x = True\n",
+ " | v > x = ...\n",
+ " | v < x = ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Because we now also have to use the `>` (greater than) and `<` (smaller than) behaviors, the types have to be an instance of the `Ord` type class. And because (like we saw in a previous lesson) to be an instance of the `Ord` type class, you have to previously be an instance of the `Eq` type class, we can remove that constraint and put the `Ord` constraint.\n",
+ "\n",
+ "Also, because we'd need a bunch of nested if-else statements, we switch to guards for a more straightforward code. And now for the final two cases:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 21,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "False"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "elemTree :: (Ord a) => a -> Tree a -> Bool\n",
+ "elemTree v EmptyT = False\n",
+ "elemTree v (Node x left right)\n",
+ " | v == x = True\n",
+ " | v > x = elemTree v right\n",
+ " | v < x = elemTree v left \n",
+ "-- Examples\n",
+ "elemTree 6 threeLevelTree\n",
+ "elemTree 17 threeLevelTree"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "If the value provided is bigger than the value of the node, we know that—if the value is in the tree—it will be in the right branch, where all the values are bigger than the value of the current node. So, the only thing we have to do is to recursively check the right subtree with the same initial value.\n",
+ "\n",
+ "And if the value is smaller than the value for the node, we know that—if the value is in the tree—it will be in the left branch, where all the values are smaller than the value of the current node. So, the only thing we have to do is to recursively check the left subtree with the same initial value.\n",
+ "\n",
+ "And that's it! We have a way to check if a value is in our data structure using the binary search algorithm."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "That's a great solution. The thing is, while you were thinking about all this, you got so focused on your thoughts that you never noticed 15 minutes had passed without you saying anything! The interviewer got a bit scared and told you that it was great meeting you and they'll communicate to let you know if you passed the interview.\n",
+ "\n",
+ "So, the takeaway is, in your next interview, remember to think out loud while working on the problems. It helps the interviewer know your thought process, and you avoid showing the face you make when binge-watching Haskell videos. Yes, the one you're making right now.\n",
+ "\n",
+ "But don't worry, you'll have more hypothetical opportunities. For now, we still have a few more things to see today. For example, the fact that the shape of the data type directs how you write functions with it."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### The shape of the data type directs how you write functions with it"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Now, this is not written in stone, but in general, you have one equation per value constructor. And if a constructor is recursive (one or N times), the equation will be recursive (one or N times).\n",
+ "\n",
+ "A few examples are:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 2,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- data Box a = Empty | Has a\n",
+ "\n",
+ "extract :: a -> Box a -> a\n",
+ "extract def Empty = def\n",
+ "extract _ (Has x) = x"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `Box a` data type has two constructors (`Empty` and `Has`), and none are recursive.\n",
+ "\n",
+ "So, when you write a function for this data type, it's likely you'll need to write two formulas (meaning two definitions)—one per constructor—and no formula will have a recursive call."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 7,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- data Sequence a = EmptyS | a :-> (Sequence a)\n",
+ "\n",
+ "elemSeq :: (Eq a) => a -> Sequence a -> Bool\n",
+ "elemSeq _ EmptyS = False\n",
+ "elemSeq x (y :-> ys) = x == y || elemSeq x ys"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `Sequence a` data type has two constructors (`EmptyS` and `:->`), and one of the constructors (`:->`) is recursive (has `(Sequence a )` as a second parameter).\n",
+ "\n",
+ "So, when you write a function for this data type, it's likely you'll need to write two formulas—one per constructor—and the formula that matches for the `:->` constructor will have a recursive call of the function you're defining."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 6,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- data Tree a = EmptyT | Node a (Tree a) (Tree a)\n",
+ "\n",
+ "elemTree :: (Ord a) => a -> Tree a -> Bool\n",
+ "elemTree v EmptyT = False\n",
+ "elemTree v (Node x left right)\n",
+ " | v == x = True\n",
+ " | v > x = elemTree v right\n",
+ " | v < x = elemTree v left"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `Tree a` data type has two constructors (`EmptyT` and `Node`), and one of the constructors (`Node`) is two times recursive (`(Tree a )` twice).\n",
+ "\n",
+ "So, when you write a function for this data type, it's likely you'll need to write two formulas—one per constructor—and the formula that matches the `Node` constructor will have two recursive calls of the function you're defining."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Of course, there are cases when this rule of thumb doesn't apply. but you can use it to get started whenever you're unsure how to define a function."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "As you can see, there's so much going on with types, value constructors, type constructors, etc. that it's hard to keep track of things. Thankfully, Haskell has a trick up its sleeve: **Kinds**! "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Kinds"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Let's go back to the simpler days. Remember the `Box` type? No? Let's see.. it had a value constructor called `Has`. Let's check its type:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 27,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "Has :: forall a. a -> Box a"
+ ],
+ "text/plain": [
+ "Has :: forall a. a -> Box a"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":t Has"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Cool, so it takes a value of any type and returns a value of type `Box a`. And what's up with that `Box` type? How can I know more about it? If you try to check the type of a type, you get an error:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 28,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "![](\"../images/diagram_purefunc_generic.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "What we mean by input and output is crucial here. A function's input can be only the values we provide as arguments, and its output is the value it returns.\n",
+ "\n",
+ "For example:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_purefunc_lame.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `lame` function takes a single numeric parameter and returns the value multiplied by three. The output of this function depends exclusively on the value we provide as input. So, every time we apply this `lame` function to four, we'll get twelve."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_purefunc_max6.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Even if we don't explicitly show the input of `max6`, we know that because `filter` is partially applied, it takes a list of `Integers`. (I simplified the signature a bit.) Same as before, the output depends exclusively on the value we provide as input. So, every time we apply this `max6` function to the same list, we'll get the same result.\n",
+ "\n",
+ "And, of course, functions are curried. So if a function looks like it takes multiple arguments, it actually takes a single parameter and returns a function that takes another single parameter, and so on, until all parameters are applied, and we get the final value. If we use the same parameters, we get the same result. And in every intermediate step, we also get the same intermediate result."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "All good so far. But what if we don't have the input yet?\n",
+ "\n",
+ "What if we want to make an interactive program? A website? Or a game? When we write our program, we have no idea what the user will do with it. We can't know in advance if a player in our game will move to the left or right. Or if a user on our website will click on a specific button or not. \n",
+ "\n",
+ "Those things happen while running the program, so there's no way for the programmer to pass them as inputs of a function.\n",
+ "\n",
+ "I mean, we could, but imagine if we chose them beforehand. A game that always does and finishes the same way. Without any way for the player to interact with it. That sounds more like a movie. Still not bad. Until you realize that you can't even show the image on the screen because that would entail sending and receiving information from your computer's screen while running the program. So, if you run this \"game,\" you're basically using your computer as a very expensive heater.\n",
+ "\n",
+ "The only way to provide our program with the information and capabilities it needs is to give it a method to interact with the real world.\n",
+ "\n",
+ "And for that, Haskell uses IO actions."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Introduction to IO Actions "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Before starting with IO actions, I'll address the elephant in the room. I just told you that everything we coded so far was pure, and we couldn't interact with it. But we've been interacting with our functions and passing arguments since lesson one! That's because we've been cheating by using GHCi, which performs IO actions in the background without explicitly telling us. So, at the end of the day, if we want our program to interact with the real world, we still need IO actions."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "***IO action* (or just *action*/*computation*)** can interact with and change the world outside our program. "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The name IO action gives room for misinterpretation. When we talk about IO actions, we're not talking about the input and output of the function. We talk about the input and output between our program and the real world. IO actions can interact with and change the world outside our program. They might or might not interact with the world, but they CAN. That's key. They are **allowed** to interact with the world.\n",
+ "\n",
+ "These IO actions are what we call a side effect."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "**A side effect is any observable effect other than the effect of returning a value.**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "That's why all the functions we've written so far have been pure. The only thing they did was to return a value. It might sound a bit abstract, so let's see a few examples so we can build up our intuition:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "- Obtain the result of what a person typed on the keyboard."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_IO_keyboard.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Notice that IO actions are on top of the diagram. We represented functions with boxes that took their inputs from the left and returned the outputs on the right. But now that we're dealing with actions, we indicate side effects at the top of the diagram with arrows going both in and out because side effects can both send and receive information."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "- Show some text, an image, or something on the screen."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_IO_screen.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "- Call an API or a database (it doesn't really matter what you do)."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_IO_api.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Ok, so we are clear about the idea of IO actions. But how does Haskell handle those IO actions?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## IO actions under the hood"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Now, I'm going to show you the definition of the type that alows us to safely interact with the real world using IO actions. A heads up! Don't try to understand the code. We'll only use it to create a mental model of what's happening under the hood.\n",
+ "\n",
+ "Without further ado, here's the `IO` type:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "newtype IO a = IO (State# RealWorld -> (# State# RealWorld, a #))\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `IO` type constructor has a single `IO` value constructor.\n",
+ "\n",
+ "The interesting part is the function passed as a parameter of the value constructor. It takes the state of the real world, does something to it, and returns a tuple containing the new state of the real world and a value of type `a` that was generated while all that was happening."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Aren't the designers of Haskell a bunch of smarty-pants? If you give a function the state of the whole real world, that function can do anything! Talk to databases, access files on your computer, allow penguins to fly, anything!\n",
+ "\n",
+ "We'll use it to print stuff on the screen, though.\n",
+ "\n",
+ "Of course, this is not what is really happening under this seemingly magical type. But we can think of it this way. The IO type is actually an abstract type."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "**An abstract data type is a type whose representation is hidden 🫣 but provides associated operations.**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "So, the inner workings of IO are hidden. And instead, we get a bunch of functions and actions that use this type. Which means:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "**We don't use the IO constructor directly. We use functions and actions that operate with IO values.**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "So there you go, that's as far as we're going to go about this. If you want to know more, there are tons of tutorials out there, or you could even explore the source code itself! But I'd recommend waiting until you're more fluent in Haskell to tackle that challenge."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Now, let's switch to the practical side. In practice, we don't care about the details of how the interaction with the real world is handled. We don't even care about how the `IO` type is defined! The only thing we care about is that, if we use it properly, the compiler will handle the details, and we won't get any surprises when running our code. So let's learn how to properly use the `IO` type."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## IO actions in practice"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_IO_something.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The `IO a` type tells us that `something` is an IO action that first interacts with the real world and then returns a value of type `a`.\n",
+ "\n",
+ "For example:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "action1 :: IO Bool -- Performs IO and returns a Bool\n",
+ "\n",
+ "action2 :: IO Int -- Performs IO and returns an Int\n",
+ "\n",
+ "action3 :: IO (Double -> Char) -- Performs IO and returns a function\n",
+ "\n",
+ "action4 :: IO () -- Performs IO and returns ()\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "There are three key things to note here:\n",
+ "1. One is that, after performing the action, we get a VALUE of the specified type we can use in our code.\n",
+ "2. The other is that the action returns a value AFTER performing the IO action. We CAN NOT get that value without interacting with the real world.\n",
+ "3. And finally, we see a new type in the last action: The unit type."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "### The unit type"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This is the unit type:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "data () = ()\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "We see that it has only one value constructor that takes no parameters (also called a nullary constructor). So, it's a type that has only one possible value (`()`). Also, notice that the type and the value have the same name. \n",
+ "\n",
+ "But wait! Why do we learn about this just now? Well, because, until now, we've been working with pure functions. If the only thing a pure function does is to return `(),` why do you even bother to use that function? Just use the value directly! And if a function takes the unit value as a parameter, why do you even bother requiring it if it's always the same value? Just remove that parameter and use the unit inside the function directly! \n",
+ "\n",
+ "So, when you think about it, we could remove the unit type from any pure function and lose nothing. BUT! Now that we're dealing with actions and side effects, there are plenty of cases when we don't care about what the action returns as a value because we care only about the side effect it performs. Take printing something on the screen or deleting a file. We don't need something in return. We care only about the side effect.\n",
+ "\n",
+ "That's why, now, it makes sense to have this type. To represent a value that we don't care about.\n",
+ "\n",
+ "If it doesn't quite click, don't worry, we'll see a couple of real-life examples during this lesson. Let's start wit how to retrieve the input from a user."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Interacting with the real world (`getChar`, `getLine`, and `putStrLn`)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The most basic IO action I can think of is `getChar`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/diagram_IO_getChar.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This function performs the IO action of asking the user to write a single character on the standard input. As soon as the user writes that character, it takes it and finishes the IO action. The value of type `Char` it returns is the character the user wrote. We can run the function here to see how that looks."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 17,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "![](\"../images/diagram_IO_getLine.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This one performs the IO action of asking the user to write a line on the standard input. And the value of type `String` it returns is the text the user wrote until it pressed Enter."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 4,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "![](\"../images/diagram_IO_putStrLn.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "`putStrLn` is a function that takes a string as input and returns an IO action. And what does the action returned by `putStrLn` do?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "\n", + "
![](\"../images/diagram_IO_putStrLn_Hi.png\")
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "It prints the `String` we previously passed as a parameter to the standard output.\n",
+ "\n",
+ "As an example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 20,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Hello World from inside the program!"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "putStrLn \"Hello World from inside the program!\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "In this case, `putStrLn` is applied to the `String` and returns an action of type `IO ()`. Then, because we're using a Jupyter notebook, it automatically performs the action, and we get the `String` in our standard output below the cell."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "But check this out:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 21,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "x = putStrLn \"Hello World from inside the program!\" "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "If we run the last cell, we don't get the `String` in our standard output. That's because we didn't ask for the action to be performed. We just named it `x`, and that's it. We never actually need the action to be performed, so Haskell didn't perform it.\n",
+ "\n",
+ "And that's another property of actions. They are what in programming are called first-class values."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Actions are first-class values"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "It means that you can treat actions the same as any other value. For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 23,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- putStrLn is an example of a function that returns an action\n",
+ "\n",
+ "\n",
+ "-- Bind to names\n",
+ "x = putStrLn \"Hello World from inside the program!\"\n",
+ "\n",
+ "\n",
+ "-- Put them inside lists or other data structures\n",
+ "listOfActions :: [IO ()]\n",
+ "listOfActions = [putStrLn \"a\", putStrLn \"b\"]\n",
+ "\n",
+ "\n",
+ "-- Pass them as function parameters\n",
+ "fakeLength :: [IO ()] -> Int\n",
+ "fakeLength list = 1 + length list"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "And, if we run the `fakeLenghth` function passing the `listOfActions` as parameters..."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 24,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "3"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "fakeLength listOfActions"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "We don't get any of the messages in the standard output because none of the actions inside the list are performed! Why should they be performed? We just asked about the length of the list, not the values it contains. Remember that Haskell is lazier than a cat sunbathing. It won't do anything unless it has to.\n",
+ "\n",
+ "So, until they are performed, IO actions are just plans to do something, programs to be run, or actions to be performed. And because the side effects aren't performed while evaluating all those expressions, we can keep reasoning about our code like we're used to. And only care for the actual side effects when we ask Haskell to perform them.\n",
+ "\n",
+ "So, how can we ask Haskell to perform a few different actions? By composing them with special operators."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Composing IO actions (`>>` and `>>=` operators)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "We'll create a few simple bots to learn how to compose IO actions"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### Rude bot"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The first one is a rude bot. As soon as you interact with it, it yells at you.\n",
+ "\n",
+ "It starts with a simple message:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 25,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Hey!"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "rudeBot :: IO ()\n",
+ "rudeBot = putStrLn \"Hey!\"\n",
+ "\n",
+ "rudeBot"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The bot has to catch its breath before yelling at you again, so we'll add the next phrase in a second action. To do that, we'll introduce the \"then\" operator:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "(>>) :: IO a -> IO b -> IO b\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This is a specialized signature specifically for IO actions. And as you can see, the operator takes two actions as inputs: `IO a` and `IO b`. It first executes `IO a`, ignores the result (whatever this `a` is), and returns the `IO b` action.\n",
+ "\n",
+ "If this were a pure operator, the implementation would look like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 28,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "5"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "'a'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "pureThen :: a -> b -> b\n",
+ "x `pureThen` y = y\n",
+ "\n",
+ "\n",
+ "3 `pureThen` 5\n",
+ "\n",
+ "3 `pureThen` 5 `pureThen` 6 `pureThen` 'a'"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "We'd be just throwing away the first value and returning the second.\n",
+ "\n",
+ "But! Because we're dealing with IO actions, this operator has some secret sauce that allows it to perform the first IO action before returning the second one. More specifically:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "(>>) :: IO a -> IO b -> IO b\n",
+ "\n",
+ "```\n",
+ "\n",
+ "\n",
+ "**The `>>` operator sequentially composes two actions, discarding any value produced by the first.**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 31,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "a\n",
+ "b\n",
+ "c"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "abc :: IO ()\n",
+ "abc = putStrLn \"a\" >> putStrLn \"b\" >> putStrLn \"c\"\n",
+ "\n",
+ "abc"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "`abc` is an action composed by multiple actions.\n",
+ "\n",
+ "When we ask Haskell to perform the `abc` action, it first performs the `putStrLn \"a\"` action and discards the result, then performs the `putStrLn \"b\"` action and discards the result, and finally, performs the `putStrLn \"c\"` action and returns whatever the last action returns. So, because `putStrLn \"c\"` returns the unit after the side effects, the `abc` action also returns the unit after the side effects."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "The direction of the arrows indicates the direction of the sequence. We perform actions from left to right.\n",
+ "\n",
+ "Now, let's use this operator to finish the rude bot:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 30,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Hey!\n",
+ "Get out of my lawn!"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "rudeBot :: IO ()\n",
+ "rudeBot = putStrLn \"Hey!\" >> putStrLn \"Get out of my lawn!\"\n",
+ "\n",
+ "rudeBot"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Exactly what we wanted!\n",
+ "\n",
+ "But maybe we could make it even ruder."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### An even ruder bot"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "How could we make this bot more annoying? Hmm... I know! Let's make it seem interested in us and then yell at us! So it also wastes our time.\n",
+ "\n",
+ "So, we'll make the bot ask our name, completely ignore it, and then yell at us. All that with this simple code:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 32,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "\n",
+ " GHCi the Haskell REPL allows you to load a Haskell file with the
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We've been coding in Haskell for a while now. But everything has been quite simple and short. That's why, if you've been doing your homework, we've been always writting our whole code in a single file.\n",
+ "\n",
+ "But what if we're making a more complex application? Like a website, a game, or a blockchain? How many thousands of unreadable code lines would that single file have? The naive solution is to split it into a bunch of files. But that stil doesn't solve many of problems we would have. That's why we use modules."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## That's it for today!"
+ ]
+ }
+ ],
+ "metadata": {
+ "celltoolbar": "Slideshow",
+ "kernelspec": {
+ "display_name": "Haskell",
+ "language": "haskell",
+ "name": "haskell"
+ },
+ "language_info": {
+ "codemirror_mode": "ihaskell",
+ "file_extension": ".hs",
+ "mimetype": "text/x-haskell",
+ "name": "haskell",
+ "pygments_lexer": "Haskell",
+ "version": "8.10.7"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/lessons/13-Modules.ipynb b/lessons/13-Modules.ipynb
new file mode 100644
index 00000000..bceb7446
--- /dev/null
+++ b/lessons/13-Modules.ipynb
@@ -0,0 +1,1592 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "# Modules"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Outline\n",
+ "\n",
+ "* Importing Modules\n",
+ " * Controlling environments\n",
+ " * Controlling namespaces\n",
+ "* Creating our own Modules\n",
+ "* The Prelude and Standard Libraries"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ ":l command. There, it is not relevant whether the file has a main function or not. Once the file is loaded into GHCi you can call any of the functions or types defined in the file and test them if they work as you expected. If you load a main.hs file into GHCi that imports some user-defined modules, they will also be included as in the compilation process.\n",
+ "\n",
+ " \n",
+ " The video and written lessons differ because the video format allows for clear explanations through refactoring code, and the written one is more suitable for sequential explanations. \n",
+ " \n",
+ " Use this to your advantage. If something doesn't make sense in one medium, maybe it will in the other!\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Crudely speaking, a Haskell module is just a collection of related functions, types, and type classes that can be imported and used in your code. But they are more than just that."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "**Modules allow us to structure, reuse, and maintain our code and environment.**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "But before learning how to create our own modules, let's see how we can use pre-defined ones."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "## Importing Modules"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "\n",
+ "We're going to import many modules several times during this lesson. So, if you run the cells sequentially, you will encounter errors when you shouldn't. In those cases, restart the Kernel (In the Kernel menu above) to get rid of all the imports and run only the cell you're on, skipping all the previous ones.\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Let's say your app needs to manipulate files and folders. We can use a module called `System.Directory` that has a bunch of functions, actions, and types related to file and directory manipulation.\n",
+ "\n",
+ "To import this module, we use the `import` keyword followed by the name of the module:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "import System.Directory\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This must be done before defining any functions, so imports are usually done at the top of the file. By adding this line of code, we gain access to all the functions, actions, types, and typeclasses of the `System.Directory` module. You can check everything that comes with this module here (link).\n",
+ "\n",
+ "One of the functions provided is `listDirectory`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "listDirectory :: FilePath -> IO [FilePath]\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "It takes a directory path of type `FilePath` (which is just a type synonym for String) and returns an IO action that, when performed, returns a list of all entries (files and directories, everything) inside the directory we passed as parameter.\n",
+ "\n",
+ "So, if we use it to check what's inside the current directory of this JupyterNotebook, we get:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 2,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"23-State-Monad.ipynb\",\"21-Reader-Monad.ipynb\",\"24-Monadic-functions.ipynb\",\"09-Creating-parameterized-and-recursive-types.ipynb\",\"04-Pattern-matching.ipynb\",\"jupyter-tutuorial.ipynb\",\"ourProgram.o\",\"rise.css\",\"simpleProgram.hs\",\"06-Recursion-and-folds.ipynb\",\"22-Writer-Monad.ipynb\",\"simpleProgram\",\"ourProgram.hi\",\"13-Bits-Bytes.ipynb\",\"10-Creating-Type-Classes.ipynb\",\"15-Learning-on-your-own-and-project.ipynb\",\"16-Semigroup-and-Monoid.ipynb\",\"03-Conditions-and-helper-constructions.ipynb\",\"14-Handling-Errors.ipynb\",\"19-Aeson.ipynb\",\"hello.hi\",\"02-Functions-Data-Types-and-Signatures.ipynb\",\"ourSourceCode.hi\",\"hello.o\",\"17-Functor.ipynb\",\"11-Basic-IO.ipynb\",\".ipynb_checkpoints\",\"20-Monad.ipynb\",\"12-Pragmas-Modules-and-Cabal.ipynb\",\"25-Monad-Transformers.ipynb\",\"18-Applicative.ipynb\",\"ourSourceCode.o\",\"01-Introduction-to-haskell.ipynb\",\"08-Creating-non-parameterized-types.ipynb\",\"05-Improving-and-combining-functions.ipynb\",\"07-Intro-to-Type-Classes.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory\n",
+ "\n",
+ "listDirectory \".\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, the current folder contains the files of all the lessons we covered so far."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, let's say we want to write a function to find files inside the current directory that contain a certain String as part of their name. Something like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "import System.Directory\n",
+ "\n",
+ "find' :: String -> IO [FilePath]\n",
+ "find' str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = -- filter entries\n",
+ " return found\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "First, we get a list of all the files and directories using listDirectory, and then we filter them. \n",
+ "\n",
+ "We could easily create the filtering function ourselves with some pattern matching and recursion. But realistically, this sounds like a common-enough function to be available as a library. And it is!!\n",
+ "\n",
+ "There's also a module called [`Data.List`](https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-List.html) that contains dozens of functions to work with lists.\n",
+ "\n",
+ "One of them is called `isInfixOf`. It takes two lists and returns `True` if the first list is contained, wholly and intact, anywhere within the second. Exactly what we need, so let's use it:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 25,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"11-Basic-IO.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory\n",
+ "import Data.List\n",
+ "\n",
+ "find' :: String -> IO [FilePath]\n",
+ "find' str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = filter (str `isInfixOf`) entry\n",
+ " return found\n",
+ "\n",
+ "find' \"11\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Awesome! Because we have access to modules with pre-written code, we don't have to implement everything by ourselves!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Ok, so the function looks good, but it has a weird name. Why not just call it `find` without the `'`?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now JupyterNotebook is, again, doing some magic to avoid errors. But if we tried to change the name of the function to `find` without the `'` and compile this code as a regular Haskell program (which you will be able to do after this lesson), we'd get this error:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "```\n",
+ "Ambiguous occurrence ‘find’\n",
+ " It could refer to\n",
+ " either ‘Data.List.find’,\n",
+ " imported from ‘Data.List’ at YourFileName.hs:3:1-16\n",
+ " (and originally defined in ‘Data.Foldable’)\n",
+ " or ‘YourFileName.find’, defined at YourFileName.hs:13:1\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The error is clear. We have two functions with the same name. One in our file and one that came when we imported `Data.List`. So the compiler doesn't know which one we're referring to.\n",
+ "\n",
+ "There are multiple solutions to this. "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### Controlling the environment"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The easiest solution, of course, is to change the name of our function:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 11,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"11-Basic-IO.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory\n",
+ "import Data.List\n",
+ "\n",
+ "findEntry :: String -> IO [FilePath]\n",
+ "findEntry str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = filter (str `isInfixOf`) entry\n",
+ " return found\n",
+ "\n",
+ "findEntry \"11\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "But this doesn't solve the underlying issue that our environment is polluted with dozens of functions and types of both `System.Directory` and `Data.List` that we're not planning to use. Which can cause all sorts of troubles."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "A better solution is to import a specific function or type instead of the whole module. We can easily do it like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 26,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"11-Basic-IO.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory (listDirectory) -- import lsitDirectory from System.Directory\n",
+ "import Data.List (isInfixOf) -- import isInfixOf from Data.List\n",
+ "\n",
+ "find :: String -> IO [FilePath]\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = filter (str `isInfixOf`) entry\n",
+ " return found\n",
+ "\n",
+ "find \"11\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We add the functions inside a parenthesis on the right. And if we need to import more than one, we add it separated by a comma.\n",
+ "\n",
+ "For example, if we want to sort the entries before returning them, we can import the `sort` function from `Data.List` and use it like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 36,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"08-Creating-non-parameterized-types.ipynb\",\"09-Creating-parameterized-and-recursive-types.ipynb\",\"10-Creating-Type-Classes.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory (listDirectory)\n",
+ "import Data.List (isInfixOf, sort) -- import isInfixOf and sort from Data.List\n",
+ "\n",
+ "find :: String -> IO [FilePath]\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry -- filter and sort\n",
+ " return found\n",
+ "\n",
+ "find \"Creating\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And we can keep adding the functions we need when we need them."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Finally, if we happen to need many functions of a module, importing them one by one might be cumbersome. Also, we might end up with a huge list of functions and types that contain almost the whole module.\n",
+ "\n",
+ "For those cases, you can use the `hidden` keyword. For example, let's say our `find` function is just one of many in our file. And we need to use a lot of functions provided by `Data.List`.\n",
+ "\n",
+ "We can change the import like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 42,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"08-Creating-non-parameterized-types.ipynb\",\"09-Creating-parameterized-and-recursive-types.ipynb\",\"10-Creating-Type-Classes.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory (listDirectory)\n",
+ "import Data.List hiding (find) -- import everything from Data.List, except `find`\n",
+ "\n",
+ "find :: String -> IO [FilePath]\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry\n",
+ " return found\n",
+ "\n",
+ "find \"Creating\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Here, we're importing everything from `Data.List` except for the `find` function.\n",
+ "\n",
+ "And, same as before, you can hide more functions and types by adding them inside those parentheses separated by commas."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's how you can control your environment while importing modules.\n",
+ "\n",
+ "But there's one more case we don't have a solution for. What if we import two modules that have functions with the same name?\n",
+ "\n",
+ "For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 51,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "\n",
+ "If you run the previous cell,
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "By adding the `qualified` keyword after `import`, instead of adding the `listDirectory` to our environment, we create a new one called `System.Directory` that contains it.\n",
+ "\n",
+ "That way, each time we want to use `listDirectory`, we have to look for it inside the `System.Directory` namespace.\n",
+ "\n",
+ "This solves our previous problem:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 5,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[\"08-Creating-non-parameterized-types.ipynb\",\"09-Creating-parameterized-and-recursive-types.ipynb\",\"10-Creating-Type-Classes.ipynb\"]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import System.Directory (listDirectory)\n",
+ "import Data.List hiding (find)\n",
+ "import qualified Data.Map\n",
+ "\n",
+ "find :: String -> IO [FilePath]\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry\n",
+ " return found\n",
+ "\n",
+ "find \"Creating\"\n",
+ "\n",
+ "-- 👇 More code that uses `Data.Map.filter` from Data.Map\n",
+ "-- ..."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, we don't have errors no more. Now that we `qualified` the `Data.Map` import, we're still importing everything from that module, including the `filter` function. But all that is inside the `Data.Map` namespace, so it doesn't get mixed with the functions/types/type classes in our main environment."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And, to show how we would use code from `Data.Map`, let's take that list of filtered and ordered entries and transform them into a map:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 10,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "fromList [(1,\"08-Creating-non-parameterized-types.ipynb\"),(2,\"09-Creating-parameterized-and-recursive-types.ipynb\"),(3,\"10-Creating-Type-Classes.ipynb\")]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import Data.List hiding (find)\n",
+ "import System.Directory (listDirectory)\n",
+ "import qualified Data.Map\n",
+ "\n",
+ "find :: String -> IO (Data.Map.Map Int String)\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry\n",
+ " let foundMap = Data.Map.fromList $ zip ([1 ..] :: [Int]) found -- List to Map\n",
+ " return foundMap\n",
+ "\n",
+ "find \"Creating\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We only added a single line of code. As we said before, maps store associations between unique keys and values. We have the values but without keys!\n",
+ "\n",
+ "We'll use the `zip` function to assign a unique key to each value. As we saw on the recursion lesson's homework, the `zip` function takes two lists and returns a list of tuples with the corresponding pairs.\n",
+ "\n",
+ "We're zipping an infinite list of ordered numbers starting from one and the list of filtered and sorted entries. So, we should get a list of pairs with a number as the first element and an entry as the second.\n",
+ "\n",
+ "Conveniently enough, the `Data.Map` module provides a function called `fromList` that takes a list of pairs and returns a value of type `Map`. In this case, the value it returns is of type `Map Int String` because the keys are `Int` and the values are `String`."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "With this final feature, we've gained complete control of our environments. Although, writing `Data.Map` everywhere gets old pretty quickly. And if we qualify imports with longer names or qualify several modules, our code starts to get cluttered and harder to read, like this sentence.\n",
+ "\n",
+ "Haskell allows us to rename the namespace to a more convenient one. For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 1,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "fromList [(1,\"08-Creating-non-parameterized-types.ipynb\"),(2,\"09-Creating-parameterized-and-recursive-types.ipynb\"),(3,\"10-Creating-Type-Classes.ipynb\")]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import Data.List hiding (find)\n",
+ "import System.Directory (listDirectory)\n",
+ "import qualified Data.Map as Map -- Renamed namespace\n",
+ "\n",
+ "find :: String -> IO (Map.Map Int String)\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry\n",
+ " let foundMap = Map.fromList $ zip ([1 ..] :: [Int]) found -- List to Map\n",
+ " return foundMap\n",
+ "\n",
+ "find \"Creating\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "listDirectory \".\" will work because Jupyter's environment already has System.Directory imported without qualifying it. If you want to reproduce this error, you'll have to restart the kernel and run the above cell first.\n",
+ "\n",
+ " Notice that module names are capitalized, if you are renaming them, this new name has to be capitalized as well!\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And as a final tip, we can combine all these different techniques. For example, if two modules do kind of the same thing and don't have any name clashes, we could give both namespaces the same name and treat them as if they came from a single module.\n",
+ "\n",
+ "This doesn't apply right now, but there's an import combination that does. Our `find` function looks pretty good. But one thing that bothers me is that `Map.Map`. I don't mind the `Map.fromList`. Actually, I prefer it! That lets me know that `fromList` comes from the `Data.Map` module. But `Map.Map` is kind of redundant. Of course that the `Map` type constructor comes from the `Data.Map` module!\n",
+ "\n",
+ "Let's combine a couple of imports to avoid this redundancy!:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "fromList [(1,\"08-Creating-non-parameterized-types.ipynb\"),(2,\"09-Creating-parameterized-and-recursive-types.ipynb\"),(3,\"10-Creating-Type-Classes.ipynb\")]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import Data.List hiding (find) \n",
+ "import System.Directory (listDirectory)\n",
+ "import qualified Data.Map as Map hiding (Map) -- import qualified + Rename namespace + hide Map\n",
+ "import Data.Map (Map) -- Import only Map\n",
+ "\n",
+ "find :: String -> IO (Map Int String)\n",
+ "find str = do\n",
+ " entry <- listDirectory \".\"\n",
+ " let found = sort $ filter (str `isInfixOf`) entry\n",
+ " let foundMap = Map.fromList $ zip ([1 ..] :: [Int]) found\n",
+ " return foundMap\n",
+ " \n",
+ "find \"Creating\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "By hiding the `Map` type constructor from the qualified import and importing it separately, we essentially removed the `Map` type constructor from the `Map` namespace and added it to our main namespace.\n",
+ "\n",
+ "Everything else is the same, but now, the signature of `find` is easier to read."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "That's pretty much everything about importing modules and managing your environment. But remember, we said modules also allow us to better structure, reuse, and maintain our code? Well, let's see how!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Creating your own module"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Since modules are just plain Haskell files that can be imported into other Haskell files, it is easy to create a module on your own."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Let's say we want another version of the `sum` function that returns an error if we apply it to the empty list instead of the value 0 that `sum` returns."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "To create a module that exposes such a module, we first create a Haskell file that we call `SumNonEmpty.hs`. At the top of this file, we write a module statement like\n",
+ "```haskell\n",
+ "module SumNonEmpty where\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "With this statement, we defined the name of our module as `SumNonEmpty`, which again should start with an upper case letter.\n",
+ "\n",
+ "**It is good practice to have the module's name as the name of the file**, though this is not mandatory."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And now, we can write the code that our module provides:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 1,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "module SumNonEmpty where\n",
+ "\n",
+ "data MyData a b = Error a | Result b deriving (Show)\n",
+ "\n",
+ "sumNonEmpty :: Num a => [a] -> MyData String a\n",
+ "sumNonEmpty [] = Error \"List is empty\"\n",
+ "sumNonEmpty xs = Result (sum xs)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's pretty much it! We created our own module. \n",
+ "\n",
+ "Now we can import it in another file (in the same folder) like any other module:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 2,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "0"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "6"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Error \"List is empty\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Result 6"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import SumNonEmpty\n",
+ "\n",
+ "sum [] -- 0\n",
+ "sum [1..3] -- 6\n",
+ "\n",
+ "sumNonEmpty [] -- Error \"List is empty\" \n",
+ "sumNonEmpty [1..3] -- Result 6"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In the previous example, the exported module is in the same folder as the file that imports it. But they could be in different places. In that case, the imports themselves express where the code is located."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "For example, in this case:\n",
+ "\n",
+ "```haskell\n",
+ "import Data.Time.Calendar\n",
+ "import Data.Time.Clock.System\n",
+ "```\n",
+ "\n",
+ "We can infer that the imports translate to the next file structure:\n",
+ "\n",
+ "```\n",
+ "Data\n",
+ " | \n",
+ " |--- Time\n",
+ " |\n",
+ " |--- Calendar.hs \n",
+ " |--- Clock\n",
+ " | \n",
+ " |--- System.hs\n",
+ " \n",
+ "```\n",
+ "\n",
+ "Where the `Calendar` module is inside the `Data/Time/Calendar.hs` file, and the `System` module is inside the `Data/Time/Clock/System.hs` file."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In contrast to import restrictions, as we did until now, Haskell also gives you control over exports. That is, what the module exposes to the outside world.\n",
+ "\n",
+ "In the above example, our module exports all that is declared in its file. But there are plenty of cases when you don't want that. For example, when you create a helper function that is meant to be used only inside the module, like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 4,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "module SumNonEmpty1 where\n",
+ "\n",
+ "errorMessage1 = \"List is empty\"\n",
+ "\n",
+ "data MyData1 a b = Error1 a | Result1 b deriving (Show)\n",
+ "\n",
+ "sumNonEmpty1 :: Num a => [a] -> MyData1 String a\n",
+ "sumNonEmpty1 [] = Error1 errorMessage1\n",
+ "sumNonEmpty1 xs = Result1 (sum xs)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In this case, anyone that imports `SumNonEmpty1` has access to `errorMessage`. But it doesn't make sense to use this error message outside the `sumNonEmpty` definition. So there's no reason for the consumer of the module to be able to access it!\n",
+ "\n",
+ "The solution is simple: Explicitly instantiate what the module exports. Like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 5,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "module SumNonEmpty2 (sumNonEmpty2, MyData2) where\n",
+ "\n",
+ "errorMessage2 = \"List is empty\"\n",
+ "\n",
+ "data MyData2 a b = Error2 a | Result2 b deriving (Show)\n",
+ "\n",
+ "sumNonEmpty2 :: Num a => [a] -> MyData2 String a\n",
+ "sumNonEmpty2 [] = Error2 errorMessage2\n",
+ "sumNonEmpty2 xs = Result2 (sum xs)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ " Note: It is common practice to put one export per line if they don't fit in one line.\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "By explicitly stating that the module exports `sumNonEmpty, MyData`, everything else inside the module becomes inaccessible to the end user (the one that imports it). As you can see here:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 6,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Result2 10.5"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "\n",
+ " \n",
+ " The video and written lessons differ because the video format allows for explanations through exemplification, and the written one is more suitable for sequential explanations. \n",
+ " \n",
+ " Use this to your advantage! 😃 If something doesn't make sense in one medium, maybe it will in the other!\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Cabal"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "tags": []
+ },
+ "source": [
+ "[Cabal](https://cabal.readthedocs.io/en/stable/intro.html) is a system for building and packaging Haskell libraries and programs. The name **cabal** stands for *Common Architecture for Building Applications and Libraries*.\n",
+ "\n",
+ "The term cabal is overloaded. It can refer to either: cabal-the-spec (.cabal files), cabal-the-library (code that understands .cabal files), or cabal-the-tool (the `cabal-install` package which provides the `cabal` executable);\n",
+ "\n",
+ "Because these three usually work in tandem, we're going to refer to all three as a single \"thing\" called Cabal."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "This lecture assumes you already have Cabal installed in your system; If you don't, please refer to the previous \"Installing Haskell Locally\" lesson. \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Cabal makes it easier for developers to:\n",
+ "- Use other developer's packages\n",
+ "- Create and share their own libraries\n",
+ "- Configure how to build and run tests and executables\n",
+ "- etc."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "By default, Cabal uses [Hackage](https://hackage.haskell.org/) as the place to look for libraries needed by the developer.\n",
+ "\n",
+ "Hackages is a central package archive that has thousands of Haskell libraries and programs ready for you to use them."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Cabal uses a local index of Hackage to resolve dependencies, so you always want to keep it updated. To do that, you can run:\n",
+ "\n",
+ "```\n",
+ "cabal update\n",
+ "```\n",
+ "\n",
+ "(See [here](https://cabal.readthedocs.io/en/stable/cabal-commands.html#cabal-update) the documentation.)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Now, we're ready to start our first Haskell project! 😄"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Creating a new Haskell project"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "To create a new Haskell project that follows the cabal architecture, we use the `cabal init` command:\n",
+ "\n",
+ "```\n",
+ "cabal init\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "When we run this command, Cabal is going to start asking a bunch of questions about the software we want to build. **You can change everything later by modifying the `.cabal` file, so don't worry too much about it!**"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "After answering all those questions, Cabal will create files and folders inside your current directory. So make sure to create a directory and go inside before running `cabal init`!\n",
+ "\n",
+ "Depending on your chosen options, you might have a different folder structure. But it should look mostly like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "```\n",
+ "Project\n",
+ " |-- app\n",
+ " | |-- Main.hs\n",
+ " |-- CHANGELOG.md\n",
+ " |-- Project.cabal\n",
+ " |-- LICENSE\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "- The `Project` folder is the folder containing your Haskell project\n",
+ "- The `app` folder contains the source code for your application (by default, a single `Main.hs` file.\n",
+ "- The `CHANGELOG.md` file to record the changes between versions.\n",
+ "- The `Project.cabal` file contains all the configuration to build and execute your executables, library, and tests (if any).\n",
+ "- The `LICENESE` file containing the license of the software"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Although this is likely how Cabal creates your project, it's common for Haskell projects to have the next folder structure:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "```\n",
+ "Project\n",
+ " |-- app\n",
+ " | |-- Main.hs\n",
+ " |-- src\n",
+ " |-- ...\n",
+ " |-- CHANGELOG.md\n",
+ " |-- Project.cabal\n",
+ " |-- LICENSE\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "The difference is that most of the source code is inside the `src` folder, and the `app` folder only contains the `Main` action.\n",
+ "\n",
+ "It doesn't make a real difference in the final result, so do as you please.\n",
+ "\n",
+ "And now that we have our project ready to go, here there are a few key commands:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "- `cabal build`: It builds your executable or library based on the contents of the source code and the `.cabal` file.\n",
+ "- `cabal exec Project`: It executes `Project`. The actual name of the executable is inside the `.cabal` file.\n",
+ "- `cabal run`: It runs `cabal build` and `cabal exec` in sequence. This is a convenient command to avoid the repetitive work of running the same two commands every time we change something.\n",
+ "- `cabal test`: Runs the tests specified in the `.cabal` file. (We won't work with tests in this lesson.)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "As you can see, everything depends on the `.cabal` file. So let's learn about it!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Going over the Cabal file"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "The `.cabal` file contains rules in a similar format as YAML files. Let's see the most common ones, starting with the informational:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "```\n",
+ "cabal-version: 3.0\n",
+ "-- The cabal-version field refers to the version of the .cabal\n",
+ "-- specification and can be different from the cabal-install\n",
+ "-- (the tool) version and the Cabal (the library) version you\n",
+ "-- are using.\n",
+ "-- The way we write this (ForestGame.cabal) file changes over\n",
+ "-- time with new versions. By stating the version we use, Cabal\n",
+ "-- will be able to interpret it.\n",
+ "-- Starting from the specification version 2.2, the cabal-version\n",
+ "-- field must be the first thing in the cabal file.\n",
+ "\n",
+ "\n",
+ "-- The name of the package.\n",
+ "name: ForestGame\n",
+ "\n",
+ "-- The package version.\n",
+ "-- See the Haskell package versioning policy (PVP) for standards\n",
+ "-- guiding when and how versions should be incremented.\n",
+ "-- https://pvp.haskell.org\n",
+ "-- PVP summary: +-+------- breaking API changes\n",
+ "-- | | +----- non-breaking API additions\n",
+ "-- | | | +--- code changes with no API change\n",
+ "version: 0.1.0.0\n",
+ "\n",
+ "-- A short (one-line) description of the package.\n",
+ "synopsis: A cool game\n",
+ "\n",
+ "-- A longer description of the package.\n",
+ "description: This game is really, reeeally cool! Trust me.\n",
+ "\n",
+ "-- The license under which the package is released.\n",
+ "license: MIT\n",
+ "\n",
+ "-- The file containing the license text.\n",
+ "license-file: LICENSE\n",
+ "\n",
+ "-- The package author(s).\n",
+ "author: Robertino Martinez\n",
+ "\n",
+ "-- An email address to which users can send suggestions, \n",
+ "-- bug reports, and patches.\n",
+ "maintainer: robertino.martinez@iohk.io\n",
+ "\n",
+ "-- Category to find our package if we upload it to Hackage\n",
+ "category: Game\n",
+ "\n",
+ "-- The type of build used by this package. Leave it as it is\n",
+ "-- or remove it entirely. We won't use Custom builds.\n",
+ "build-type: Simple\n",
+ "\n",
+ "-- Extra doc files to be distributed with the package, such\n",
+ "-- as a CHANGELOG or a README.\n",
+ "extra-doc-files: CHANGELOG.md\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "As you can see, we're adding information about ourselves and the package, but no instructions on how to process the source code yet.\n",
+ "\n",
+ "Now, let's see we want to build the executable of our game. For that, we can use the `executable` sections. Let's see one:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "```\n",
+ "executable ForestGame\n",
+ " main-is: Main.hs\n",
+ " other-modules: Forest.Level1\n",
+ " , User.Actions.Move\n",
+ " build-depends: base ^>=4.16.4.0\n",
+ " , random ^>=1.2.1.1\n",
+ " hs-source-dirs: app, src\n",
+ " default-language: Haskell2010\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We indicate what is part of the `executable` section using indentation. Let's go over one by one:\n",
+ "\n",
+ "- `executable ForestGame`: Indicates that we're specifying an executable called ForestGame.\n",
+ "- `main-is`: We specify where the main module resides.\n",
+ "- `other-modules`: We specify auxiliary modules used by our executable.\n",
+ "- `build-depends`: Declares the library dependencies (with version) required to build the current package component. In this case, we depend on the `base` and `random` libraries. (see the video of this lesson to know how we use them.)\n",
+ "- `hs-source-dirs`: Root directories for the module hierarchy. In this case, instead of using only `app`, we chose to use `app` and `src` to contain our source code.\n",
+ "- `default-language`: The version of Haskell we want to use."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "With only the informational and executable instructions, we have everything needed for Cabal to be able to build our executable.\n",
+ "\n",
+ "Although, we also have the option to create:\n",
+ "- [A library](https://cabal.readthedocs.io/en/stable/cabal-package.html#library),\n",
+ "- [Tests suites](https://cabal.readthedocs.io/en/stable/cabal-package.html#test-suites),\n",
+ "- And more executables if we wanted to. (For example, if we wanted to have \"development\" and \"production\" executables that differ in some way.)\n",
+ "\n",
+ "\n",
+ "You can configure A LOT with Cabal. Usually, the best course of action is to figure out what you want to do and search [Cabal's documentation](https://cabal.readthedocs.io/en/stable/index.html) to see how to do it."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### Building and running our executable"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Now that we have our cabal file, we can build and execute our software without worrying about resolving dependencies, downloading packages, etc.\n",
+ "\n",
+ "We can just run:\n",
+ "\n",
+ "```\n",
+ "cabal build\n",
+ "```\n",
+ "\n",
+ "And Cabal will do everything for us! 😄🙌\n",
+ "\n",
+ "And once everything is built, we can run any executable with:\n",
+ "\n",
+ "```\n",
+ "cabal exec ForestGame\n",
+ "```\n",
+ "\n",
+ "Of course, while developing, you'd have to build+execute quite a lot. That's why Cabal has a special command for that:\n",
+ "\n",
+ "```\n",
+ "cabal run\n",
+ "```\n",
+ "\n",
+ "When running `cabal run`, Cabal will check if any source code changed, and if it did, it will rebuild only the files that changed and then run the executable! Extremely convenient! 😎"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "For a more step-by-step explanation with a real-world example, take a look at the corresponding video lesson! 😃 \n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## Language extensions and Pragmas"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Usually, in most mainstream programming languages, your language for a specific version always works the same. For example, Python 3.7 and 3.10 are different, but Python 3.7 will always have the same syntax and functionality. The only way you can change how Python works or its syntax is by changing the version of the language.\n",
+ "\n",
+ "Haskell is different. Haskell has language extensions.\n",
+ "\n",
+ "Language extensions are a way to modify how the Haskell compiler interprets your code. By activating language extensions, you essentially change the Haskell language to have a particular feature you want or need. This way, you can tailor the language to your taste or use case!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "You can add language extensions by specifying them in your `.cabal` file or by adding a **Language Pragma** to the top of the file you want the extension to be active.\n",
+ "\n",
+ "The syntax to add a language pragma to a Haskell file is by adding this statement at the top of the file:\n",
+ "\n",
+ "```\n",
+ "{-# LANGUAGE extension_name #-}\n",
+ "```\n",
+ "\n",
+ "Let's see a few examples!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### NumericUnderscores"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Let's say we're working with an app that uses big numbers, such as a game:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 4,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "15049231"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "userGems = 15894231\n",
+ "\n",
+ "purchase gems item = gems - item\n",
+ "\n",
+ "level1Vest = 52000\n",
+ "level2Vest = 147000\n",
+ "level3Vest = 845000\n",
+ "tank = 314159265358\n",
+ "\n",
+ "-- Usage example:\n",
+ "purchase userGems level3Vest"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "It works. But because we're using large numbers, it's easy to mess up. It's hard to tell the number at a glance. One more zero looks kind of the same! 🤷♂️\n",
+ "\n",
+ "That's when the `NumericUnderscores` language extension comes in.\n",
+ "\n",
+ "This language extension adds support for expressing underscores in numeric literals. That is, underscores in numeric literals are ignored when `NumericUnderscores` is enabled. For instance, the numeric literal 1_000_000 will be parsed into 1000000 when `NumericUnderscores` is enabled. The underscores are only there to assist human readers.\n",
+ "\n",
+ "So, if we activate the extension, we can rewrite our code like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 5,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "15049231"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "{-# LANGUAGE NumericUnderscores #-}\n",
+ "\n",
+ "userGems = 15_894_231\n",
+ "\n",
+ "purchase gems item = gems - item\n",
+ "\n",
+ "level1Vest = 52_000\n",
+ "level2Vest = 147_000\n",
+ "level3Vest = 845_000\n",
+ "tank = 314_159_265_358\n",
+ "\n",
+ "-- Usage example:\n",
+ "purchase userGems level3Vest"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "As you can see, the final result didn't change. But we effectively changed Haskell's syntax so that numeric values can look different (can have underscores)!\n",
+ "\n",
+ "Now, let's use a language extension that does a more significant change: `TypeApplications`."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "### TypeApplications"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "`TypeApplications` allows you to instantiate one or more of a polymorphic function’s type arguments to a specific type.\n",
+ "\n",
+ "For example, the function `read` is of type:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 6,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "read :: forall a. Read a => String -> a"
+ ],
+ "text/plain": [
+ "read :: forall a. Read a => String -> a"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":t read"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ " The `forall a.` part indicates that all `a` are the same type. And `Read a =>` indicates that the same type is an instance of the `Read` type class.\n",
+ " \n",
+ "So, if we do:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 42,
+ "metadata": {},
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "Prelude.read: no parse"
+ ]
+ }
+ ],
+ "source": [
+ "read \"4\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "In this JupyterNotebook, we get that `Prelude.read: no parse` error. But in a real scenario, we'd get a long error that starts with:\n",
+ "\n",
+ "```\n",
+ "Ambiguous type variable ‘a0’ arising from a use of ‘parse’\n",
+ " prevents the constraint ‘(Read a0)’ from being solved.\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We get an error because the literal `4` could be any numeric value, and we're not indicating which one. So the compiler doesn't know which instance of `Read` to use. Should it use the `Int` instance? The `Integer` instance? `Float`? `Double`?\n",
+ "\n",
+ "One way to solve this specific scenario is to use the `::` operator like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 13,
+ "metadata": {
+ "scrolled": true
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "(read \"4\") :: Int"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We're explicitly expressing that the `read \"4\"` expression should evaluate to an `Int`, so now the compiler knows it should use the `Read Int` instance.\n",
+ "\n",
+ "Now, instead of doing this, we can use the `TypeApplications` language extension and use the `@` keyword to apply the function to a type like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 14,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "{-# LANGUAGE TypeApplications #-}\n",
+ "\n",
+ "read @Int \"4\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "What does means comes back to the `read` type signature. If we compare the type signature of `read` and `read @Int`:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 16,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "read :: forall a. Read a => String -> a"
+ ],
+ "text/plain": [
+ "read :: forall a. Read a => String -> a"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "read @Int :: String -> Int"
+ ],
+ "text/plain": [
+ "read @Int :: String -> Int"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "{-# LANGUAGE TypeApplications #-}\n",
+ "\n",
+ ":t read\n",
+ ":t read @Int"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We see that we're specializing the type variable `a` to `Int`.\n",
+ "\n",
+ "This works in more complex scenarios. In the following example, we define the `Number` type that holds either a whole number, a decimal number, or a string of an unidentified number:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 32,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "WHOLE :: forall a b. a -> Number a b"
+ ],
+ "text/plain": [
+ "WHOLE :: forall a b. a -> Number a b"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "WHOLE @Int :: forall b. Int -> Number Int b"
+ ],
+ "text/plain": [
+ "WHOLE @Int :: forall b. Int -> Number Int b"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "WHOLE @Int @Float :: Int -> Number Int Float"
+ ],
+ "text/plain": [
+ "WHOLE @Int @Float :: Int -> Number Int Float"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "{-# LANGUAGE TypeApplications #-}\n",
+ "\n",
+ "data Number a b = WHOLE a | DECIMAL b | NAN String deriving (Show)\n",
+ "\n",
+ ":t WHOLE\n",
+ ":t WHOLE @Int\n",
+ ":t WHOLE @Int @Float"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "And if you want to specify the type of the second parameter (`b`) but leave the first type as a polymorphic one, you can use another language extension called `PartialTypeSignatures` that allows you to put wildcards in types:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 39,
+ "metadata": {
+ "scrolled": true
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "DECIMAL @Int :: forall b. b -> Number Int b"
+ ],
+ "text/plain": [
+ "DECIMAL @Int :: forall b. b -> Number Int b"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "DECIMAL @_ @Float :: forall _. Float -> Number _ Float"
+ ],
+ "text/plain": [
+ "DECIMAL @_ @Float :: forall _. Float -> Number _ Float"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "{-# LANGUAGE TypeApplications #-}\n",
+ "{-# LANGUAGE PartialTypeSignatures #-}\n",
+ "\n",
+ "data Number a b = WHOLE a | DECIMAL b | NAN String deriving (Show)\n",
+ "\n",
+ ":t DECIMAL @Int\n",
+ ":t DECIMAL @_ @Float -- Now the \"a\" type is shown as \"_\"."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Let's see this in a way that makes a real difference in the final result.\n",
+ "\n",
+ "We create the `parse` function that takes in a `String` and parses it into a value of type `Number a b` depending if it represents a `WHOLE` number, a `DECIMAL` number, or if it couldn't identify the number (`NAN`):"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 43,
+ "metadata": {},
+ "outputs": [],
+ "source": [
+ "parse :: (Read a, Read b) => String -> Number a b\n",
+ "parse inp\n",
+ " | isNumber && isDecimal = DECIMAL $ read inp\n",
+ " | isNumber = WHOLE $ read inp\n",
+ " | otherwise = NAN inp\n",
+ " where\n",
+ " validChar = \".0123456789\"\n",
+ " isNumber = all (`elem` validChar) inp\n",
+ " isDecimal = '.' `elem` inp"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "Now, if we try to use this function without indicating the type:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 44,
+ "metadata": {
+ "scrolled": true
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "Prelude.read: no parse"
+ ]
+ }
+ ],
+ "source": [
+ "parse \"98\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "We get the same error we got before because GHC can't infer the type of `98`. \n",
+ "\n",
+ "If we indicate the types, everything works fine. But not only that! **By specializing the variables `a` and `b` types when applying the `parse` function, we get to choose what kind of precision we want when parsing a whole or a decimal number!**:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 47,
+ "metadata": {
+ "scrolled": true
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "WHOLE (-9223372036854775808)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "WHOLE 9223372036854775808"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "DECIMAL 1.2345679"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "DECIMAL 1.23456789"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "NAN \"para bailar la bamba!!\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "longWhole = \"9223372036854775808\"\n",
+ "longDecimal = \"1.23456789\"\n",
+ "\n",
+ "-- 'a' 'b' \n",
+ "parse @Int longWhole\n",
+ "parse @Integer longWhole\n",
+ "parse @_ @Float longDecimal\n",
+ "parse @_ @Double longDecimal\n",
+ "parse @Int @Double \"para bailar la bamba!!\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "#### The `@` symbol"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "The `@` symbol is also used to pattern-match an entire structure (like a list, record type, etc.) while pattern-matching for its parts."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "In the example below, the `counts` function takes in a list and returns a list of tuples with the unique value and how many times the value is in the list.\n",
+ "\n",
+ "When we pattern match to extract the first value `(x:_)`, we also add `list@` that creates a variable named `list`, which is equal to the entire list `x:xs`:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 56,
+ "metadata": {},
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[('s',3),('u',2),('c',2),('e',1),('f',1),('l',2),('y',1)]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "counts :: Eq a => [a] -> [(a, Int)]\n",
+ "counts [] = []\n",
+ "counts list@(x:_) = (x, length (filter (== x) list)) : counts (filter (/= x) list)\n",
+ "\n",
+ "counts \"successfully\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "The main difference between when we use the `@` sign to apply a type or to pattern match is the space to is left: \n",
+ "- Pattern matching: it has no space to its left `list@(x:xs)`\n",
+ "- Apply type: it has a space `read @Int`\n",
+ "\n",
+ "That's how the compiler knows which is which."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "There are a ton of language extensions ([see this list for reference](https://downloads.haskell.org/ghc/latest/docs/users_guide/exts/table.html)), and we'll use new ones when needed. But for now, make sure to do your homework!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "\n",
+ "The homework is based on the example in the video lesson. If you feel lost, take a look at the part where I explain the example's code.\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {},
+ "source": [
+ "## That's it for today! Make sure to do the homework! 😁"
+ ]
+ }
+ ],
+ "metadata": {
+ "kernelspec": {
+ "display_name": "Haskell",
+ "language": "haskell",
+ "name": "haskell"
+ },
+ "language_info": {
+ "codemirror_mode": "ihaskell",
+ "file_extension": ".hs",
+ "mimetype": "text/x-haskell",
+ "name": "haskell",
+ "pygments_lexer": "Haskell",
+ "version": "8.10.7"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/lessons/15-Handling-Errors.ipynb b/lessons/15-Handling-Errors.ipynb
new file mode 100644
index 00000000..19c7d925
--- /dev/null
+++ b/lessons/15-Handling-Errors.ipynb
@@ -0,0 +1,1922 @@
+{
+ "cells": [
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "# Handling🧑🚒🧯💨 🔥errors🔥 in Haskell"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Haskell is a compiled language, so we can subdivide all possible errors into:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "- ✅ Compile time errors 🙌"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Compile time errors are awesome! We LOVE compile-time errors. Because that means our program had something wrong in it, and our compiler found it and reported it to us **BEFORE** it reached the end user. At the end of the day, the most important thing is that our users enjoy our software and don't encounter:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "- ❌ Run time errors 🫣"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Runtime errors are the worst! Because these errors happen while running the program, they can and do, happen to end users. Users then get angry and stop paying, give us a 1-star review, or something like that."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Compared to most other programming languages, Haskell is exceptionally good at avoiding runtime errors. To the point that many say the phrase, \"in Haskell, if it compiles, it works.\"\n",
+ "\n",
+ "This is thanks, in large part, to its purity and powerful type system that can catch those errors at compile time. Essentially, moving many errors from runtime to compile time.\n",
+ "\n",
+ "Although, this doesn't mean that we can forget about runtime errors. As we said in previous lessons, even if we were able to write perfect code (which we cannot), we're still running it in the real world. Where computers run out of memory, files that should exist don't, internet connections fail, etc. And on top of that, users do unimaginable things with our software."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "So, in this lesson, we will learn both how to handle runtime errors and how to use the type system to move some of those errors to compile time so we catch them with the compiler's assistance.\n",
+ "\n",
+ "More specifically:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "# Outline\n",
+ "\n",
+ "- There're always `Exception`s to the rule\n",
+ "- Speed-running `Exception`s with a dumb self-driving 🤖 car 🚗\n",
+ " - I'm the `Exception` cause I have `class` 😎\n",
+ " - `throw` all the `Exception`s you want. I'll `catch` them all!\n",
+ "- `Maybe` give me a value? 🙏\n",
+ " - Benefits of optional values\n",
+ "- Ok, you `Either` give me a value or a reason why you didn't!\n",
+ "- From `Exception`s to optional values\n",
+ "- Tradeoffs\n",
+ " - So, what should I use?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Let's get started!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## There're always `Exception`s to the rule"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Let's write a simple program to calculate the velocity of an object based on a number written in a file and the input of a person:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "calcVel :: IO ()\n",
+ "calcVel = do\n",
+ " d <- readFile \"aNumber.txt\"\n",
+ " putStrLn \"Loaded the distance traveled by the object.\"\n",
+ " putStrLn \"Provide the time it took:\"\n",
+ " t <- getLine\n",
+ " let v = (read d :: Int) `div` read t\n",
+ " putStrLn $ \"The object's velocity is about: \" ++ show v\n",
+ " putStrLn \"Thank you for using this program!\"\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "In this program, we read a file (the distance traveled by an object) and ask the user to provide a number (the time it took) using IO actions. Then, we use the `read` function to parse them into `Int` values and apply the `div` function to get the velocity of the object. In the end, we print back the velocity and a thank-you message.\n",
+ "\n",
+ "This is a pretty simple program. It compiles, and if we have a file in the `aNumber.txt` with a number in it, and the user provides a valid number, it works!!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Sadly, the real world is messy, and unexpected things can–and do–happen. When something unexpected happens, that's when we get an `Exception`. For example, here are a few (but not all) of the possible `Exception`s that the program could throw at us:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "If there's no `aNumber.txt` file:\n",
+ "```\n",
+ "*** Exception: aNumber.txt: openFile: does not exist (No such file or directory)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "If we don't provide valid numbers to `read`:\n",
+ "```\n",
+ "*** Exception: Prelude.read: no parse\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "If we provide `0`(zero) as time:\n",
+ "```\n",
+ "*** Exception: divide by zero\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Currently, all these `Exception`s cause our program to crash. But, of course, a robust program should not collapse if something unexpected happens. Luckily, we have a couple of ways to handle these `Exception`s."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Speed-running `Exception`s with a dumb self-driving 🤖 car 🚗"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Handling exceptions in Haskell is not a small subject. It has its own mechanism, and you can go crazy creating your own hierarchical error structures, using alternative libraries, etc. But you have more important things to learn before that. So, in this lesson, we're going to speedrun the subject in a way you'll have an overall idea of how it works, and you'll be able to handle common runtime errors."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Ok. Let's say we want to build an AI for a self-driving car. AI is all the rage right now, so we're going to build a prototype to get some VC funding and improve it later.\n",
+ "\n",
+ "To simplify the problem, we'll start with a car that can only go straight and react to traffic lights:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "dumbAICar :: IO ()\n",
+ "dumbAICar = do\n",
+ " putStrLn \"What color is the traffic light?\"\n",
+ " color <- getLine\n",
+ " putStrLn $ \"\\nThen I'll \" ++ nextMove color\n",
+ " dumbAICar\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "In these complex cases, it's usual to have several different systems, sensors, and predictive models. But! Because no one invested in our AI yet, we don't have money to spend on a sensor. So we'll be the sensor. We'll sit inside the car and type the color of the traffic light.\n",
+ "\n",
+ "Once we have a `String` containing the color, we provide it to the `nextMove` function that eventually should send a signal to the gas and brakes. For now, it prints the next move on the screen.\n",
+ "\n",
+ "Now, let's create the `nextMove` function. We're taking a `String` that represents the color of traffic lights, so we could do something like:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "data TrafficLight = Red | Yellow | Green deriving (Show, Read)\n",
+ "\n",
+ "nextMove :: String -> String\n",
+ "nextMove color = case read color of\n",
+ " Red -> \"Stop!\"\n",
+ " Yellow -> \"Waaaait...\"\n",
+ " Green -> \"Go!\"\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This is technically right. But we have two problems:\n",
+ "\n",
+ "1. If we write something different than any of those three constructors, our program halts, and subsequently, the car crashes with us inside.\n",
+ "2. And the other one is that the error provided in the case it fails doesn't provide much actionable information:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```\n",
+ "*** Exception: Prelude.read: no parse\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Let's solve the second issue first by providing a more expressive exception."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### I'm the `Exception` cause I have `class` 😎"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "To create our own `Exception`, we just need create a good old data type, and make it an instance of the `Exception` type class.\n",
+ "\n",
+ "So, lets create a data type that represents the possible failures:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "data TrafficLightException = TrafficLightIsOff | WrongColor String\n",
+ " deriving (Show)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "One value for when the traffic light is off, and another when the sensor provides values that don't make sense. Now, this is still what we call \"normal\" values. To make them exceptional, we have to import the `Control.Exception` module:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "\n",
+ "Note: We have to import
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "And make the type an instance of `Exception` like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Exception TrafficLightException\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Notice we don't define the behaviors with the `where` keyword. That's because we don't have to! All the `Exception` type class functions have default implementations, so we only need to indicate that the `TrafficLightException` can use those.\n",
+ "\n",
+ "This conveniently allows us to use exceptional values without entering into how the `Exception` type class is defined and the needy-greedy of the mechanism. Things that would take too long to properly go over and would touch subjects that are a bit outside of the beginner's scope.\n",
+ "\n",
+ "So, yeah! That's all we need to do! With that single line of code, we transformed our \"normal\" type into an \"exceptional\" type. That means we can throw and catch values of type `TrafficLightException` like any other built-in exception.\n",
+ "\n",
+ "But what does that mean exactly?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### `throw` all the `Exception`s you want. I'll `catch` them all!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Throwing exceptions means halting the current program's execution and sending a signal with some information about what went wrong. That signal is the `Exception`.\n",
+ "\n",
+ "We have a couple of options to throw exceptions. We're going to go with:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "throwIO :: Exception e => e -> IO a\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "As the name and type suggest, `throwIO` gets a type that's an instance of the `Exception` type class and throws an exception within the `IO` context. We return a value within the impure `IO` context because exceptions can have side effects.\n",
+ "\n",
+ "Technically, you can throw exceptions from pure code using a function called `throw` (without the IO). But it's highly recommended to use `throwIO` to maintain our pure code exception-free."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Ok, let's change the `nextMove` function to manually parse the `String` instead of using the `read` function and throw as many exceptions as we want:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "nextMove :: String -> IO String\n",
+ "nextMove color = case color of\n",
+ " \"Red\" -> return \"Stop!\"\n",
+ " \"Yellow\" -> return \"Wait!\"\n",
+ " \"Green\" -> return \"Go!\"\n",
+ " \"Black\" -> throwIO TrafficLightIsOff\n",
+ " _ -> throwIO . WrongColor $ color ++ \" is not a valid color!\"\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "And here's when we encounter one of the downsides to throwing exceptions. We don't want to throw from pure code (because, due to laziness, it is hard to predict), so we throw from the IO context. This means our previously pure `nextMove` function is now impure, and we lose all the advantages that come with purity. We'll talk more about this at the end of the lecture.\n",
+ "\n",
+ "So! Instead of using `read`, we parse the `String` by hand and provide extra cases to handle our newly created exceptions. \n",
+ "\n",
+ "Specifically, if we apply `nextMove` to one of the two final patterns, instead of returning a value, we throw an exception:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ ">> nextMove \"Black\"\n",
+ "*** Exception: TrafficLightIsOff\n",
+ "\n",
+ "\n",
+ ">> nextMove \"Rainbow\"\n",
+ "*** Exception: WrongColor \"Rainbow is not a valid color!\"\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This solves the issue of not providing enough information because we can add custom messages that help when debugging the program. Keep in mind that this function can be buried inside a massive program. But because the exception is so specific, we instantly know what's wrong and where we should go to fix it.\n",
+ "\n",
+ "But, if we leave it like this, we just created a fancier way for our program to halt. 🤦♂️ To make our program more resilient, we're going to catch, handle, and recover from this exception! 💪"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Same as with `throwIO`, there are several ways to catch and handle an `Exception`. One of them is using the `catch` function:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "catch :: Exception e -- Type e is an instance of Exception\n",
+ " => IO a -- The computation to run\n",
+ " -> (e -> IO a) -- Handler to invoke if an exception is raised\n",
+ " -> IO a -- We always return a value of type IO a\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "This function executes the `IO` action that we provide as the first parameter. If everything goes well, it returns the result, and that's it. BUT! If some exception arises, it catches it and gives it to the handling function we provide as a second argument. In that handling function, we can write all sorts of code to address this exception and resume our program.\n",
+ "\n",
+ "For example, we can use `catch` to handle our `TrafficLightException` like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "dumbAICar :: IO ()\n",
+ "dumbAICar = do\n",
+ " putStrLn \"What color is the traffic light?\"\n",
+ " color <- getLine\n",
+ " response <- nextMove color `catch` handler\n",
+ " putStrLn $ \"I'll \" ++ response\n",
+ " dumbAICar\n",
+ " \n",
+ " where\n",
+ " handler :: TrafficLightException -> IO String\n",
+ " handler e = do\n",
+ " -- do whatever you want...\n",
+ " putStrLn $ \"WARNING: \" ++ show e\n",
+ " case e of\n",
+ " TrafficLightIsOff -> return \"Proceed with caution.\"\n",
+ " WrongColor _ -> return \"Stop the car and shut down!\"\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "Now, it doesn't matter if the String isn't a valid color. The `nextMove` function will raise an exception. And, because the exception is of type `TrafficLightException`, the `dumbAICar` action will be able to catch it and give it to our `hanlder` to recover from it.\n",
+ "\n",
+ "In this case, if the traffic light is off, the car will proceed with caution. And if we happen to encounter any other color, that means something is wrong with the sensor. But instead of halting the program and leaving a moving car without a driver, the program continues execution and stops the car."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "Control.Exception, which is the standard library module that contains code related to exceptions. \n",
+ "\n", + ">> dumbAICar\n", + "What color is the traffic light?\n", + "> Red\n", + "I'll Stop!\n", + "What color is the traffic light?\n", + "> Green\n", + "I'll Go!\n", + "What color is the traffic light?\n", + "> Black\n", + "WARNING: TrafficLightIsOff\n", + "I'll Proceed with caution.\n", + "What color is the traffic light?\n", + "> Rainbow\n", + "WARNING: WrongColor \"Rainbow is not a valid color!\"\n", + "I'll Stop the car and shut down!\n", + "" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, at least we won't crash if something's wrong with the sensor.\n", + "\n", + "If the exception is of any other type, it will keep propagating up the stack looking for a `catch` that can handle that specific type. If it doesn't find any, the program won't be able to recover.\n", + "\n", + "And that's the end of our speedrun. There are a ton of things we didn't cover, but everything revolves around this notion of throwing and catching exceptions. If you can foresee an exception and know what the program should do in that case, you can implement a handler to recover from it.\n", + "\n", + "And how do we know the usual exceptions we could encounter? Look no further than in the same `Control.Exception` module from where we imported the `Exception` type class." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "For example, if you're dealing with numeric operations, you can take a look at the `ArithException` data type:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "data ArithException\n", + " = Overflow\n", + " | Underflow\n", + " | LossOfPrecision\n", + " | DivideByZero\n", + " | Denormal\n", + " | RatioZeroDenominator \n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And if you're dealing with Arrays, you might encounter an exception of type `ArrayException`:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "data ArrayException\n", + " = IndexOutOfBounds String -- Indexed an array outside its bounds\n", + " | UndefinedElement String -- Evaluated an uninitialized element\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Etc, etc. \n", + "\n", + "In all those cases, all you have to do is catch the exception of a specific type and provide a handler function to recover from it. There may be no sensible way to continue. In those cases, we want to shut down gracefully. By shutting down gracefully, I mean cleaning up any open connections, killing orphan processes, writing some logs, etc. It depends on what you're doing." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now... The exceptions mechanism is great, but there's also a different way to handle runtime errors, and that is more straightforward and idiomatic. An that's using optional values." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## `Maybe` give me a value? 🙏" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "In Haskell and other functional programming languages, we have this notion of \"opotional values.\" Those are values representing the possibility that a function may or **may not** return a meaningful value." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "In Haskell, optional values are represented by the `Maybe` type:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "data Maybe a = Nothing | Just a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As you can see, it's a simple type. It has one nullary constructor (a constructor that doesn't have parameters) and one constructor with a polymorphic value. The major implementation difference with the other way to handle `Exceptions`, is that `Maybe` is a \"normal\" type. It's not special in any way other than what we (the developers) interpret by it.\n", + "\n", + "So, the critical thing to remember is how to interpret it when we encounter it. The `Maybe` type represents a value that might or might not be there. So, when you see something like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "someFunction :: Int -> String -> Maybe Bool\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We read it as:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "`someFunction` takes an `Int` and a `String`, and `Maybe` returns a `Bool`." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "That's it.\n", + "\n", + "Now, let's see it in practice. One common example is to show how we can safely divide by zero.\n", + "\n", + "In your regular day-to-day math, dividing by zero doesn't make any mathematical sense. When programming, it's the same. So, if we divide by zero using the `div` function like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "55 `div` 0\n", + "\n", + "*** Exception: divide by zero\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Our program throws an Exception.\n", + "\n", + "Let's solve that without using the exception mechanism." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "One of the first things one could think to resolve the issue is to create a function that handles this specific case separately, sort of like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "safeDiv :: Integral a => a -> a -> a\n", + "safeDiv x 0 = ????? -- 0? -1? 9999999999999? \n", + "safeDiv x y = x `div` y\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The `saveDivide` function takes two values that are instances of the `Integral` type class (the one that provides the `div` behavior) and returns a value of the same type. In the first case, we pattern-match to handle the case when the denominator is zero. And in the second, all other cases. The second case is easy... we know that `y` is not zero, so we can use `div` with full confidence. But how should we handle the first case? There's no number we could return that correctly represents this situation!\n", + "\n", + "\n", + "Here's when the `Maybe` type shines! Using `Maybe`, we can modify our function to have the option of not returning a value at all!!:" + ] + }, + { + "cell_type": "code", + "execution_count": 1, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Just 5" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Nothing" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "safeDiv :: Integral a => a -> a -> Maybe a\n", + "safeDiv _ 0 = Nothing\n", + "safeDiv x y = Just (x `div` y)\n", + "\n", + "\n", + "15 `safeDiv` 3\n", + "15 `safeDiv` 0" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As you can see, if there's no sensible value to be returned, we can plug the `Nothing` value. Notice that by avoiding the possibility of dividing by zero from the get-go, we bypass the exception altogether! No need to handle exceptions if they never happen!\n", + "\n", + "The price that we have to pay is that the value is now wrapped around a constructor. So we have to unwrap it before using it." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, let's use the `safeDiv` function in a program. To do that, we'll keep with the speed theme and create a program that takes the distance traveled by an object and the time it took as inputs, and it returns the velocity:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "main :: IO ()\n", + "main = do\n", + " putStrLn \"provide the distance traveled by the object:\"\n", + " d <- getLine\n", + " putStrLn \"provide the time it took:\"\n", + " t <- getLine\n", + " case read d `safeDiv` read t of\n", + " Just v -> putStrLn $ \"The velocity is: \" ++ show v\n", + " Nothing -> do\n", + " putStrLn \"\\nThe time can't be zero!\"\n", + " main\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "By using this technique, we completely avoided a runtime error. It doesn't matter which numbers the user chooses. Our program won't crash! 🙌 But wait... What if the user doesn't write valid numbers as inputs? What if the user writes letters or symbols instead of numbers? 😵\n", + "\n", + "In that case, the `read` function won't be able to parse the `String` to a number, and... you guessed it... our program halts. 🫣\n", + "\n", + "Worry not! We have a solution! But before that, I'm going to extract some functions so the code fits in the slides:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "vel :: Int -> Int -> Maybe Int\n", + "vel dist time = dist `safeDiv` time\n", + "\n", + "getData :: IO (String, String)\n", + "getData = do\n", + " putStrLn \"provide the distance traveled by the object:\"\n", + " d <- getLine\n", + " putStrLn \"provide the time it took:\"\n", + " t <- getLine\n", + " return (d, t)\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Extracting the `velocity` function isn't of much help now, but it will be in the future. And extracting the `getData` action hides code we don't care about. So our `main` function looks like this now:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "main :: IO ()\n", + "main = do\n", + " (d, t) <- getData\n", + " case vel (read d) (read t) of\n", + " Just v -> putStrLn $ \"The velocity: \" ++ show v\n", + " Nothing -> do\n", + " putStrLn \"\\nThe time can't be zero!\"\n", + " main\n", + "\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Much cleaner! Ok, so we would like a `read` function that can avoid returning a meaningful value if it's unable to parse the value. Luckily for us, a function like that already comes with our base libraries, and it's inside the `Text.Read` module:" + ] + }, + { + "cell_type": "code", + "execution_count": 2, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Just 57" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Nothing" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "import Text.Read (readMaybe)\n", + "\n", + "-- readMaybe :: Read a => String -> Maybe a\n", + "\n", + "readMaybe \"57\" :: Maybe Integer\n", + "readMaybe \"B00!\" :: Maybe Integer" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "By using `readMaybe` instead of `read`, we avoid **all runtime errors due to a bad user input**:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "import Text.Read (readMaybe)\n", + " \n", + "main :: IO ()\n", + "main = do\n", + " (d, t) <- getData\n", + " case vel (readMaybe d) (readMaybe t) of\n", + " Just v -> putStrLn $ \"The velocity is: \" ++ show v\n", + " Nothing -> do\n", + " putStrLn \"\\nPlease, provide valid numbers (time /= zero)!\"\n", + " main\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We do have a small issue now. `velocity` cannot take `Int`s directly anymore because `readMaybe` returns a `Maybe`. So we have to modify `velocity` like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "vel :: Maybe Int -> Maybe Int -> Maybe Int\n", + "vel (Just dist) (Just time) = dist `safeDiv` time\n", + "vel _ _ = Nothing\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We pattern match for the cases when both are parsed correctly and pass the `Int`s to the `safeDiv` function. We ignore all other cases and return `Nothing`." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "There are many pre-defined functions that use the `Maybe` type, both in the standard libraries and in libraries made by other developers. When you encounter them, you can use them all in the same way. Pattern-match, handle both cases, and you're good to go!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "### Benefits of optional values" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now that we understand how to use the `Maybe` data type, let's talk about the benefits it provides:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- You can handle the absence of value" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "`Maybe` provides a type-safe way to indicate the absence of a value, preventing many forms of runtime errors." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- Your code is more robust" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Using `Maybe` forces you to explicitly handle both the case when you have a value and when you don't. Ensuring you address all possibilities and write more robust code." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- Allows you to express uncertainty" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Optional values allow the developer to express uncertainty in a way that the consumer of the function is aware of and can handle without the need to know how the function is implemented." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- You can compose optional values" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As we did in the previous examples. We provided the output of `readMaybe` as inputs to `velocity` that used `safeDiv` inside. If something went wrong at any time, the `Nothing` value would propagate throughout the function tree." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, the `Maybe` data type is not the only data type in town we can use to handle possibly problematic values. One downside of using the `Maybe` data type is that when we have several layers of optional values, we don't know what went wrong! In the previous code, for example. If we got a `Nothing` at the end, what failed? The parsing of the first value? The parsing of the second value? Or the division by zero? We have no way to find out!\n", + "\n", + "Enter the `Either` data type:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Ok, you `Either` give me a value or a reason why you didn't!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The `Either` data type is also pretty simple:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "data Either a b = Left a | Right b\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The `Either` type represents values with two possibilities: a value of type `Either a b` is either `Left a` or `Right b`. You cannot have both. This is not necessarily related to error handling or optional values. Either can be used in many scenarios to represent a binary choice.\n", + "\n", + "However, in the context of error handling, you can think of `Either` as something that builds on top of the `Maybe` data type to provide a way to log what went wrong. " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The way we use `Either` to handle errors is not forced in code but by convention. The community overall uses the `Left` constructor to hold an error value and the `Right` constructor to hold a correct value. Based on the mnemonic that \"right\" also means \"correct.\"\n", + "\n", + "So, now that we know about `Either`, let's modify `saveDiv` to let us know if we try to divide by zero:" + ] + }, + { + "cell_type": "code", + "execution_count": 3, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Right 5" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Left \"You can't divide by zero, you fool!!\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "safeDivE :: Integral a => a -> a -> Either String a\n", + "safeDivE _ 0 = Left \"You can't divide by zero, you fool!!\"\n", + "safeDivE x y = Right (x `div` y)\n", + "\n", + "\n", + "15 `safeDivE` 3\n", + "15 `safeDivE` 0" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As you can see, we chose `String` as the type parameter for `Left` so we can leave a message to the user or developer. Although using a simple `String` to leave a message is the intuitive thing to try first, using values that we could later handle programmatically is even better. Something like:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "data PermissionLevel = Guest | User | Admin\n", + "\n", + "data UIException = WrongInput String\n", + " | WrongPermission PermissionLevel\n", + " | UserDidNotLogIn\n", + "\n", + "someFunction :: Integral a => a -> a -> Either UIException a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And further down the line, we can use this extra information to do things programmatically. For example, if `Either` returns `Left UserDidNotLogIn`, we can redirect the user to the login page.\n", + "\n", + "We will stick to `String`s for today's examples. To keep it simple.\n", + "\n", + "There are also many functions already available that return `Either` values. As you might imagine, one of those is the `Either` equivalent of the `readMaybe` function:" + ] + }, + { + "cell_type": "code", + "execution_count": 4, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Right 57" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Left \"Prelude.read: no parse\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "import Text.Read (readEither)\n", + "\n", + "--readEither :: Read a => String -> Either String a\n", + "\n", + "readEither \"57\" :: Either String Int\n", + "readEither \"B00!\" :: Either String Int" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Notice how it returns what we otherwise would get as an Exception, but this time we're getting it as a plain `String`, and our program keeps running.\n", + "\n", + "With all that, let's transform the rest of the code. The main function is almost the same, we just change `readMaybe` for `readEither`. And because we can return a custom messge with the error, we print that:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "import Text.Read (readEither)\n", + "\n", + "main :: IO ()\n", + "main = do\n", + " (d, t) <- getData\n", + " case vel (readEither d) (readEither t) of\n", + " Right v -> putStrLn $ \"The object's velocity is: \" ++ show v\n", + " Left s -> do\n", + " putStrLn s\n", + " main\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The `velocity` function is the one that gets interesting. Now, we can return a message, so we can personalize it based on what went wrong:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "vel :: Either String Int -> Either String Int -> Either String Int\n", + "vel (Right d) (Right t) = d `safeDivE` t\n", + "vel (Left d) (Left t) = Left $ \"Both wrong!! d:\"++ d ++\" t:\"++ t\n", + "vel (Left d) _ = Left $ \"Wrong distance input!: \" ++ d\n", + "vel _ (Left t) = Left $ \"Wrong time input!: \" ++ t\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As you can see, the `velocity` function now explicitly handles more cases because we care about which input failed to parse. And that's pretty much it!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## From `Exception`s to optional values" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Finally, there are ways to go from one to the other. We already saw how to go from normal values to exceptions... We throw an exception.\n", + "\n", + "But what if we have an exception and we want an optional value? The easiest way to do that is using the `try` function:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "try :: Exception e => IO a -> IO (Either e a)\n", + "try ioa = (ioa >>= return . Right) `catch` (return . Left)\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The `try` function uses `catch` under the hood. `try` takes an IO action and tries to run it. If everything goes well, it returns the final result using the `Right` constructor. But, if something goes wrong, `catch` will capture all exceptions of type `e` and return them using the `Left` constructor. Same as before, if the raised exception is of a type different than `e`, it will keep propagating." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "So, let's say we want to read a file:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "main :: IO ()\n", + "main = do\n", + " contents <- putStrLn \"Where's the file?\" >> getLine >>= readFile\n", + " putStrLn $ \"result: \" ++ contents\n", + "\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "In this case, we cannot prevent the possibility of an `Exception`. We're interacting with the outside world, and unexpected things might happen.\n", + "\n", + "But! Using the `try` function, we can handle the `Exception` under the hood and only interact with optional values ourselves. Like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "main :: IO ()\n", + "main = do\n", + " ec <- try $ putStrLn \"Where's the file?\" >> getLine >>= readFile\n", + " case ec of\n", + " Left e -> do\n", + " putStrLn $ \"WARNING: \" ++ show (e :: IOException)\n", + " main\n", + " Right contents -> putStrLn $ \"result: \" ++ contents\n", + "\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "As you can see, the exception, in this case, is of type `IOException`. These are exceptions related to IO operations, like reading and writing files. And from now on, you can do whatever you want with your values following the usual execution of your program.\n", + "\n", + "OK. We learned how to handle exceptions using the exception mechanism, how to use optional values to keep our error handling within the regular execution of our program, and finally, how to move from one to the other. To end this lecture, let's compare the two of them to see what the tradeoffs are." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Tradeoffs" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "In theory, the key difference between using exceptions and optional values is that when we use optional values, we're handling errors in the program itself. We're not stopping the execution and silently propagating the error throughout the stack. The error handling happens in a specific place and is part of the normal execution of the program.\n", + "\n", + "In practice, there are more things to take into account." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "|Optional values | Exceptions |\n", + "| --- | --- |\n", + "They are evident by the types, so you know when you're dealing with them | They are hidden from you, so you're unaware of how a function can fail by only looking at its type|\n", + "| They are pure values, easy to predict | You can only catch them inside impure code, which makes your program harder to predict|\n", + "| They are easy to use | They can be complicated to use |\n", + "| Managing multiple levels of optional values may* add complexity to the code | The code complexity of the \"happy path\" stays the same, but there's added complexity elsewhere. |\n", + "| They don't compose well with functions that take the unwrapped value. Which generates a loss in modularity | They don't affect composability |\n", + "| Accidental strictness: It's not unavoidable, but it becomes easy to make our functions strict | Doesn't affect laziness and compiler optimizations |\n", + "| They can't handle asynchronous `Exceptions` cause those happen outside the code | We can `catch` asynchronous `Exceptions` |" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "### So, what should I use?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "For now:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- Try to use optional values (Maybe, Either, etc.) as much as possible to implement pure algorithms." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- If a failure is expected, it's better to explicitly indicate it with an optional type. For example, the `lookup :: (Eq a) => a -> [(a,b)] -> Maybe b` function returns a `Maybe` because it's expected that the key we asked for might not be there. " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- If the failure is a rare \"This should never happen\" case, using an `Exception` is usually the best choice." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- In many cases, the choice between exceptional and non-exceptional can be blurry. In those cases, you'll have to use your best judgment." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And finally, if you feel like this is not enough, don't worry. Further along the line, you'll encounter knowledge that will unlock new ways of handling errors and exceptions. Giving you even more flexibility!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "# That's it for today! 😄" + ] + } + ], + "metadata": { + "celltoolbar": "Slideshow", + "kernelspec": { + "display_name": "Haskell", + "language": "haskell", + "name": "haskell" + }, + "language_info": { + "codemirror_mode": "ihaskell", + "file_extension": ".hs", + "mimetype": "text/x-haskell", + "name": "haskell", + "pygments_lexer": "Haskell", + "version": "8.10.7" + } + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/lessons/16-Gaining-your-independence-and-project.ipynb b/lessons/16-Gaining-your-independence-and-project.ipynb new file mode 100644 index 00000000..bc2741dc --- /dev/null +++ b/lessons/16-Gaining-your-independence-and-project.ipynb @@ -0,0 +1,1267 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "# Gaining your independence 💪" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Outline\n", + "\n", + "* Small tips and tricks\n", + " * REPL\n", + " * Hackage\n", + " * Hoogle\n", + " * `undefined`\n", + " * Type Holes\n", + "* Section's Final Project" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## REPL" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Remember that you always have the repl available to you. And If you enter the REPL using `cabal repl`, you can also import and explore modules you downloaded using Hackage. If you want to see how it works, see the example in the video version." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Hackage\n", + "\n", + "\n", + "## https://hackage.haskell.org/" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Hackage is the Haskell community's central package archive. At the time of writing this lesson, there are over 16 thousand Haskell packages available in Hackage.\n", + "\n", + "We already saw how you can use it with Cabal to add libraries to your projects. But in the video lesson, we'll explore how to find and choose libraries and explore the documentation." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Hoogle\n", + "\n", + "\n", + "## https://hoogle.haskell.org/" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Hoogle allows you to search a commonly used subset of Haskell libraries by either function name or approximate type signature. \n", + "\n", + "This is useful in several scenarios, for example:\n", + "\n", + "1. If you want to print a string to the console but forget the name of the function, searching for \"String -> IO ()\" will provide all functions with a signature that matches your intention. \n", + "2. If you want to use a function but forget from which module it is, you can search for the function, and it will tell you where it is.\n", + "3. If you want to work with some concept, like natural numbers or web sockets, you can try searching those terms to see if any library, type, module, function, or type class roughly matches the name." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## `undefined`" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "If we look for `undefined` in Hoogle, we'll see that, in theory, it's just a fancy error. It's a value that, as soon as you evaluate it, halts your program. Of course, as we saw in the Handling Errors lesson, we don't like runtime errors! So, why I'm sharing it as a tip?\n", + "\n", + "In practice, `undefined` is a great tool to keep the type checker assisting you while working on a half-baked code. Let's see how." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Let's say we want to create a function that reads a CSV file, transforms the content into JSON format, and writes a new file with the new contents. \n", + "\n", + "First, we create newtype wrappers for both CSV and JSON values. To avoid mixing CSV and JSON values by accident and allow the compiler to provide more specific hints. Even if the underlying value in both cases is just a String.\n", + "\n", + "Then, because we don't want our program to crash if, for some reason, the reading and writing of files or the conversion fails, we'll catch the errors and return an Either:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype CSV = CSV String \n", + "newtype JSON = JSON String\n", + "\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile ...\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Ok, now we can start implementing the function. Because we're just starting and we don't have a clear idea of how we want to implement this, we'll go step by step. I'll behave naively to showcase the usefulness of `undefined`. \n", + "\n", + "Let's start by printing a message to the console and reading the file:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile = do\n", + " putStrLn \"Reading CSV file\"\n", + " rawCSV <- readFile -- ❌ typecheck: Error here!\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "If we write this, we get this error:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```\n", + "The last statement in a 'do' block must be an expression\n", + " rawCSV <- readFile\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Which is not the error we would expect. Especially because there's an even more fundamental error that the type checker is not telling us about because it's stuck in this one.\n", + "\n", + "We could be making huge mistakes like this one:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile = do\n", + " putStrLn \"Reading CSV file\"\n", + " askldj56jklsdjf564lkjsdlf -- Cat walked on the keyboard 🐈\n", + " rawCSV <- readFile -- ❌ typecheck (oblivious to the previous line): Error here!\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And we wouldn't know because the type checker is stuck with the same error as before.\n", + "\n", + "This is one of the cases when `undefined` is handy. If we add an `undefined` as the last statement of the `do` block, we're essentially telling the type checker: \"trust me, bro, from here on, everything is fine. Don't sweat it.\"\n", + "\n", + "So, the type checker, assuming everything is fine there, will continue to analyze the rest of our code and give us useful information.\n", + "\n", + "In this case, if we do this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile = do\n", + " putStrLn \"Reading CSV file\" -- ❌ typecheck: Wrong type!\n", + " askldj56jklsdjf564lkjsdlf -- ❌ typecheck: What's wrong with you?\n", + " rawCSV <- readFile -- ❌ typecheck: Where's the readFile's argument?\n", + " undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We get a bunch of helpful errors that help us realize that there's a line with gibberish, that we didn't specify the argument name of the `csvFileToJsonFile` function, and that we didn't provide the argument to the `readFile` function. So, we fix them:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile fp = do\n", + " putStrLn \"Reading CSV file\"\n", + " rawCSV <- readFile fp\n", + " undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, we have no type errors, and we can be reasonably certain that everything up until `undefined` is ok." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Another use of `undefined` is to check the behaviors during development. For example, we still have to parse the contents to CSV, convert them into JSON, and then write the new file. And on top of that, we have to do error handling. \n", + "\n", + "Instead of writing the whole thing and checking that everything works at the end, we can check the values in intermediate steps by running the code with the `undefine` there. For example, we can check the content of the files by printing them:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile fp = do\n", + " putStrLn \"Reading CSV file\"\n", + " rawCSV <- readFile fp\n", + " print rawCSV\n", + " undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, we open a REPL and run `csvFileToJsonFile \"somefile.csv\"` and we get the contents of the file printed at the console, and after that, we get an exception:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```\n", + "*** Exception: Prelude.undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Because `undefined` is just a fancy error, we'll get a runtime error if we run the program. Of course, by the time you're done with the code, there has to be no `undefined` left. `undefined` is just a tool for your convenience during a development session. You could get fired if you ship an `undefined` value to production.\n", + "\n", + "But! We don't care at this point because we're mid-development, and we just want to check if everything we coded so far is fine." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Finally, one last good use case for `undefined` is to use it as an implementation TODO. For example, let's say we keep going with our function:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile fp = do\n", + " putStrLn \"Reading CSV file\"\n", + " rawCSV <- readFile fp\n", + " let csv = parseCSV rawCSV -- ❌ typecheck: Who is parseCSV? A friend of yours?\n", + " undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "At this point, we'd have an error because there's no `parseCSV` function. And there's no `parseCSV` function because we haven't implemented it yet.\n", + "\n", + "One option would be to implement `parseCSV` right away. That would be fine. But what if, halfway through implementing it, you realize you need to implement another function? And another one. This specific case wouldn't be that complicated. But you can see how, in more complex cases, by the time you finish implementing all the internal functions, you lose track of what you had in mind for the original one.\n", + "\n", + "So, if you have a rough idea of the overall structure of the original function, you can defer implementing the internal functions until you finish implementing the original function by creating the internal functions signatures and setting the actual implementation of it as undefined. Like this: " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype CSV = CSV String deriving (Show)\n", + "newtype JSON = JSON String deriving (Show)\n", + "\n", + "csvFileToJsonFile :: FilePath -> IO (Either String JSON)\n", + "csvFileToJsonFile fp = do\n", + " putStrLn \"Reading CSV file\"\n", + " rawCSV <- readFile fp\n", + " let csv = parseCSV rawCSV\n", + " (JSON json) = csvToJson csv\n", + " writeFile \"newFile.json\" json\n", + " undefined\n", + "\n", + "parseCSV :: String -> CSV\n", + "parseCSV = undefined\n", + "\n", + "csvToJson :: CSV -> JSON\n", + "csvToJson = undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And now, each `undefined` is like a TODO item. The first indicates that you still have to add error handling. And the other two that you still have to implement those functions. You essentially split the work into three, and you can start tackling your TODOs one by one." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, let's move to the final tip of the lesson: Type holes!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Type holes" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Typed holes are a feature of GHC specifically designed to help you figure out what code to write when you're unsure.\n", + "\n", + "It works like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Let's say you're implementing a function that parses a list of `String`s into valid emails:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = undefined\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "This function verifies that the user input is a valid email by checking it contains the `@` sign. And then, it has to normalize them by converting all characters into lowercase.\n", + "\n", + "Ok. So, let's start easy by just straight-up converting Strings into Emails without doing anything.\n", + "\n", + "If we change the undefined to an underscore, we get a pretty interesting error:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = _\n", + "```\n", + "-------------------------------------------------------------\n", + "```\n", + "• Found hole: _ :: [String] -> [Email]\n", + "• In an equation for ‘parseEmails’: parseEmails = _\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:99:1)\n", + " Valid hole fits include\n", + " parseEmails\n", + " mempty\n", + " Valid refinement hole fits include\n", + " map _\n", + " concatMap _\n", + " (<$>) _\n", + " fmap _\n", + " ($) _\n", + " const _\n", + " pure _\n", + " head _\n", + " last _\n", + " id _\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "This is what type holes bring to the table in Haskell. By putting an underscore in our unfinished code, we asked the type checker for hints about what could be done there. The type checker brings all the information it can:\n", + "\n", + "- It tells us what's the type of the hole.\n", + "- Where the hole is.\n", + "- What are relevant bindings (in this case, the only relevant binding is the same function we're defining, but if we have a `where` clause or `let` bindings, those would show up as well).\n", + "- Then, it shows us which values in our scope perfectly fit the hole.\n", + "- Finally, it tells us which functions and constructors don't fit perfectly but could take us one step closer to the final answer." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "In this case, we know we have to `map` over the list of `String`s, so we take the first \"refinement hole\" suggestion and write `map` with an underscore (a new type hole) in front:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map _\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: String -> Email\n", + "• In the first argument of ‘map’, namely ‘_’\n", + " In the expression: map _\n", + " In an equation for ‘parseEmails’: parseEmails = map _\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:100:1)\n", + " Valid hole fits include Email\n", + " Valid refinement hole fits include\n", + " ($) _\n", + " const _\n", + " pure _\n", + " return _\n", + " ($!) _\n", + " (Map.!) _\n", + " head _\n", + " last _\n", + " id _\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, we get a new set of the same information but for our new hole. And, if we look at the \"Valid hole fits\", we see that the `Email` constructor is there!\n", + "\n", + "If we wrap a string with the `Email` value constructor, we get a value of type `Email`, which is exactly what we set out to do!\n", + "\n", + "So, we take the type hole suggestion and write the `Email` constructor after `map`:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map Email\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "And voilá! Our function compiles.\n", + "\n", + "But we're far from finished here. We said we wanted to filter emails that didn't contain the `@` sign, so let's do that. \n", + "\n", + "Of course, we want to filter the emails before constructing them, so we'll use function composition to add the `filter` function before the `map` function: " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map Email . filter _\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: String -> Bool\n", + "• In the first argument of ‘filter’, namely ‘_’\n", + " In the second argument of ‘(.)’, namely ‘filter _’\n", + " In the expression: map Email . filter _\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:94:1)\n", + " Valid hole fits include\n", + " null\n", + " read\n", + " Valid refinement hole fits include\n", + " (==) _\n", + " (/=) _\n", + " (>) _\n", + " (<=) _\n", + " (>=) _\n", + " (<) _\n", + " ($) _\n", + " head _\n", + " last _\n", + " id _\n", + " (Some refinement hole fits suppressed; use -fmax-refinement-hole-fits=N or -fno-max-refinement-hole-fits)\n", + " ```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Ok. So, we need a predicate. But, this time, the typed hole has a little message at the bottom. This is because it has more suggestions than the maximum allowed by default. One thing we could do to get more hints is to disable this maximum allowed by writing a pragma with the flag indicated right there like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map Email . filter _\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: String -> Bool\n", + "• In the first argument of ‘filter’, namely ‘_’\n", + " In the second argument of ‘(.)’, namely ‘filter _’\n", + " In the expression: map Email . filter _\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:94:1)\n", + " Valid hole fits include\n", + " null\n", + " read\n", + " Valid refinement hole fits include\n", + " (==) _\n", + " (/=) _\n", + " (>) _\n", + " (<=) _\n", + " (>=) _\n", + " (<) _\n", + " ($) _\n", + " notElem _\n", + " elem _\n", + " any _\n", + " all _\n", + " const _\n", + " pure _\n", + " return _\n", + " ($!) _\n", + " head _\n", + " last _\n", + " id _\n", + " ```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Now, we have more options in the \"refinement hole fits\" sections. And, if we look at them, we're reminded that we could use `elem`. We know that `elem` is a predicate that returns true if the element is inside the list, which is what we needed. We substitute `_` with `elem _` and keep going:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map Email . filter (elem _)\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: Char\n", + "• In the first argument of ‘elem’, namely ‘_’\n", + " In the first argument of ‘filter’, namely ‘(elem _)’\n", + " In the second argument of ‘(.)’, namely ‘filter (elem _)’\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:95:1)\n", + " Valid hole fits include\n", + " maxBound\n", + " minBound\n", + " Valid refinement hole fits include\n", + " head _\n", + " last _\n", + " id _\n", + " pred _\n", + " succ _\n", + " toEnum _\n", + " read _\n", + " ```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "This case is pretty obvious. We need a character to check if it is part of the `String`, and we know which character that is:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map Email . filter (elem '@')\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We're done with the filtering! Now, let's normalize the emails. Because we have to normalize the strings before wrapping them with the `Email` constructor, we do the same as before and compose a type hole:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map (Email . _) . filter (elem '@')\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: String -> String\n", + "• In the second argument of ‘(.)’, namely ‘_’\n", + " In the first argument of ‘map’, namely ‘(Email . _)’\n", + " In the first argument of ‘(.)’, namely ‘map (Email . _)’\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:98:1)\n", + " Valid hole fits include\n", + " show\n", + " reverse\n", + " cycle\n", + " init\n", + " tail\n", + " id\n", + " mempty\n", + " fail\n", + " read\n", + " Valid refinement hole fits include\n", + " (:) _\n", + " (++) _\n", + " max _\n", + " min _\n", + " map _\n", + " concatMap _\n", + " (<$>) _\n", + " fmap _\n", + " take _\n", + " drop _\n", + " ($) _\n", + " takeWhile _\n", + " dropWhile _\n", + " const _\n", + " filter _\n", + " (<>) _\n", + " mappend _\n", + " pure _\n", + " sequenceA _\n", + " foldMap _\n", + " return _\n", + " (<*>) _\n", + " (=<<) _\n", + " (<*) _\n", + " (<$) _\n", + " sequence _\n", + " ($!) _\n", + " asTypeOf _\n", + " scanl1 _\n", + " scanr1 _\n", + " showChar _\n", + " showString _\n", + " head _\n", + " last _\n", + " id _\n", + " mconcat _\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We get a huuuuuge list of options, but the one that clearly looks like the best option is to refine our hole with a `map`. We have a list of characters. So, maybe we can go through every character and return the lowercase version, one by one. So, we accept that suggestion and replace the `_` with `map _`: " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map (Email . map _) . filter (elem '@')\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: Char -> Char\n", + "• In the first argument of ‘map’, namely ‘_’\n", + " In the second argument of ‘(.)’, namely ‘map _’\n", + " In the first argument of ‘map’, namely ‘(Email . map _)’\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:100:1)\n", + " Valid hole fits include\n", + " id\n", + " pred\n", + " succ\n", + " Valid refinement hole fits include\n", + " max _\n", + " min _\n", + " ($) _\n", + " const _\n", + " pure _\n", + " return _\n", + " ($!) _\n", + " asTypeOf _\n", + " head _\n", + " last _\n", + " id _\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Ok. We know that we need a function that goes from character to character. But none of the provided ones seem to either fit perfectly or help us move in the right direction. But we have one more ace up our sleeve: Imports! \n", + "\n", + "We get those suggestions because those are the ones available in our environment. So, if we want more suggestions, we can add more to our environment. In this case, we want to work with characters, so a good initial idea would be to import a module full of functions to work with characters. The `Data.Char` module is the prime candidate. Let's do that and see which new options we get:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "import Data.Char\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map (Email . map _) . filter (elem '@')\n", + "```\n", + "---\n", + "```\n", + "• Found hole: _ :: Char -> Char\n", + "• In the first argument of ‘map’, namely ‘_’\n", + " In the second argument of ‘(.)’, namely ‘map _’\n", + " In the first argument of ‘map’, namely ‘(Email . map _)’\n", + "• Relevant bindings include\n", + " parseEmails :: [String] -> [Email]\n", + " (bound at /Users/roberm/scratchpad/typedHoles.hs:100:1)\n", + " Valid hole fits include\n", + " id\n", + " pred\n", + " succ\n", + " toLower\n", + " toUpper\n", + " toTitle\n", + " Valid refinement hole fits include\n", + " max _\n", + " min _\n", + " ($) _\n", + " const _\n", + " pure _\n", + " return _\n", + " ($!) _\n", + " asTypeOf _\n", + " head _\n", + " last _\n", + " id _\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Behold! Between the new suggestions, there's a function that perfectly fits our hole with the name of `toLower`. It looks too enticing to ignore, so let's replace it:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "{-# OPTIONS_GHC -fno-max-refinement-hole-fits #-}\n", + "\n", + "import Data.Char\n", + "\n", + "newtype Email = Email String deriving Show\n", + "\n", + "parseEmails :: [String] -> [Email]\n", + "parseEmails = map (Email . map toLower) . filter (elem '@')\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "It compiles! And it looks like we finished implementing all the functionality we wanted. And if we test the function:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "```haskell\n", + "parseEmails [\"luffy@onepiece.com\",\"ZorO@OnePiece.cOm\", \"son.goku\"]\n", + "\n", + "-- [Email \"luffy@onepiece.com\",Email \"zoro@onepiece.com\"]\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "We see that it works as expected. \n", + "\n", + "As you can see, type holes can be really useful. Especially when you're working with many polymorphic values or nested structures. Just as a final remark, you can have more than one hole at a time and name them by adding the name right after the underscore (without a space in between). Make it easier to distinguish them." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Section's Final Project (what we did so far)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "In this lesson, you're going to prove to yourself that you can code in Haskell.\n", + "\n", + "If you've been doing the homework by now, you have a couple of programs under your belt:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "* In lesson 9's homework, you built a closed and open maze (we called it Forest) solver. \n", + "* In lesson 11's homework, you had the opportunity to build a program that prints a tree-like graph representing a folder structure.\n", + "* In lesson 14, we built a CLI game in which the user tries to escape from a forest before it runs out of stamina. And in the homework of the same lesson, you added a battle system to fight golems while trying to escape.\n", + "* In lesson 15's homework, you went through and understood the code of a CLI program that you can use to manage your to-do list. And on top of that, you added error handling to fix the bugs I purposely hid in the code." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "At every step of the way, we introduced new concepts, and I provided you with thorough guidance about what to take into account and how to approach those challenges. Now, it's time for you to build something by yourself.\n", + "\n", + "Here are the requirements:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Section's Final Project (project requirements)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "* Build a Tic-Tac-Toe game.\n", + "* It has to be a CLI executable with the business logic implemented as a library.\n", + "* There has to be a single-player (against the machine) and a multiplayer (two-player) mode.\n", + "* The machine has to play randomly.\n", + "* The board has to be printed nicely on the console.\n", + "* Use any library you want. However, the provided solution will only use the `random` library and Haskell features explained up until now. So, if you're tempted to use more advanced features, you're likely overcomplicating it." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "The only way to learn how to code is by coding. So, make sure to do the project, and I'll see you on the next one." + ] + } + ], + "metadata": { + "celltoolbar": "Slideshow", + "kernelspec": { + "display_name": "Haskell", + "language": "haskell", + "name": "haskell" + }, + "language_info": { + "codemirror_mode": "ihaskell", + "file_extension": ".hs", + "mimetype": "text/x-haskell", + "name": "haskell", + "pygments_lexer": "Haskell", + "version": "8.10.7" + } + }, + "nbformat": 4, + "nbformat_minor": 4 +} diff --git a/lessons/17-Semigroup-and-Monoid.ipynb b/lessons/17-Semigroup-and-Monoid.ipynb new file mode 100644 index 00000000..0864ce57 --- /dev/null +++ b/lessons/17-Semigroup-and-Monoid.ipynb @@ -0,0 +1,2122 @@ +{ + "cells": [ + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "# Abstractions, Semigroup, and Monoid" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "This is the first lesson of the \"Abstracting Patterns\" section of the course. In this lesson, we'll cover:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Outline\n", + "\n", + "- What does it mean to abstract a pattern?\n", + "- Why abstracting patterns (in general)?\n", + "- Teaser: Why abstracting `Semigroup` and `Monoid`?\n", + "- The `Semigroup` type class\n", + "- The `Monoid` type class\n", + "- What can we do with `Semigroup` and `Monoid`?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## What does it mean to abstract a pattern?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We humans are very good at detecting patterns. For example, in the 6th lesson of this course, we wrote these functions:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "sum' :: [Int] -> Int\n", + "sum' [] = 0\n", + "sum' (x:xs) = x + sum' xs\n", + "\n", + "product' :: [Int] -> Int\n", + "product' [] = 1\n", + "product' (x:xs) = x * product' xs\n", + "\n", + "and' :: [Bool] -> Bool\n", + "and' [] = True\n", + "and' (x:xs) = x && and' xs\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We figured out that there was a repeating pattern in all of those functions, so we created a single one that contains that pattern and takes whatever is different as arguments:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "-- +/*/&& -> 0/1/True -> [Int]/[Bool] -> Int/Bool\n", + "foldr :: (a -> b -> b) -> b -> [a] -> b\n", + "foldr _ v [] = v\n", + "foldr f v (x:xs) = f x (foldr f v xs)\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And then, because we had a function that represented the abstract idea of:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "\"Applying a function to combine the first value of a list and the result of recursively applying the same function to the rest of the list\"" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Or more sucinctly:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "\"Reducing a list using a binary operator\"" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We replaced the implementation of the original functions with the abstraction like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "sum' :: [Int] -> Int\n", + "sum' = foldr (+) 0 -- We partially apply foldr\n", + "\n", + "product' :: [Int] -> Int\n", + "product' = foldr (*) 1\n", + "\n", + "and' :: [Bool] -> Bool\n", + "and' = foldr (&&) True\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "That seires of steps:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "1. Write some code.\n", + "2. Identifying a pattern.\n", + "3. Create a structure* to contain that pattern (if useful).\n", + "4. Use that structure instead of explicitly writting the pattern.\n", + "\n", + "*By \"structure,\" we mean types, functions, and type classes. Other programming languages may use different ones (like OOP classes)." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Ok, so this is what we mean when we talk about abstracting a pattern.\n", + "\n", + "As a small caveat, it's important to note that we shouldn't extract all patterns. As I said before, we humans are very good at detecting patterns, but not all of them are worthy of abstraction. But don't worry about that for now. You'll learn to tell the difference with practice." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Why abstracting patterns (in general)?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "One somewhat reasonable question would be to ask: \"Why should I abstract patterns?\" And there are several reasons, the most important ones are:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- To easily reuse code" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "As we showed in the previous `foldr` example, now you have to implement the recursive pattern once, and you can use it anywhere." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- To hide the unimportant details" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Also, in the previous example, we hid the details of how exactly we implement the recursion inside `foldr`. Thanks to that, the code becomes a short one-liner that only shows what we care about: Which binary function we apply and what is the starting value." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- To have clear and concise code that you (and others) can quickly understand" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "By using `foldr` instead of explicitly writing the pattern, the reader instantly understands what we're doing. We're folding a list. That's it. 1 second is enough to know what this line does and keep moving. " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "These reasons apply for every correctly derived abstraction. But what about `Semigroup` and `Monoid` specifically?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Teaser: Why abstracting `Semigroup` and `Monoid`?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "To make sure I get your full attention throughout the rest of this lesson, I'll share a real-world problem that becomes significantly easier by abstracting `Semigroup` and `Monoid`, and that is:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "### Scalability" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "More specifically:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "- **Scaling computations**\n", + "- **Scaling result complexity without increasing code complexity**" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "If you've worked with any programming language in production, you'll likely know this is a tough and complex problem. So, we developers need all the help we can get." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "At the end of the lesson, after learning about `Semigroup` and `Monoid`, we'll see how these abstractions allow us to more easily scale." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## The `Semigroup` type class" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "In the first example, we abstracted away a pattern into a function, and now we'll abstract away into a type class. This is not something new. If you think about it:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "``` haskell\n", + "type Num :: * -> Constraint\n", + "class Num a where\n", + " (+) :: a -> a -> a\n", + " (-) :: a -> a -> a\n", + " (*) :: a -> a -> a\n", + " negate :: a -> a\n", + " abs :: a -> a\n", + " signum :: a -> a\n", + " fromInteger :: Integer -> a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The `Num` type class is an abstraction of the properties and behaviors a number should have. All numbers should be able to be added, subtracted, multiplied, and so on. Some types we think of as numbers behave fundamentally differently in some ways. For example, we can get fractional numbers with `Float`, but we can not with `Integer`. So, the `Num` type class abstracts away only the behaviors every number-like type should have." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We are going to do the same someone else did for numbers, but for a different concept. Take a look at this code:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(\"Abstract \" ++ \"me\") ++ \"!\" -- \"Abstract me!\"\n", + "\"Abstract \" ++ (\"me\" ++ \"!\") -- \"Abstract me!\"\n", + "\n", + "(2 * 3) * 4 -- 24\n", + "2 * (3 * 4) -- 24\n", + "\n", + "(True && False) && True -- False\n", + "True && (False && True) -- False\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "What do we have in common in all three cases? Well, in all three cases, there's a binary function (a function that takes two parameters) that somehow combines two values of one type to produce a new value of the same type:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "(++) :: [a] -> [a] -> [a]\n", + "\n", + "(*) :: Num a => a -> a -> a\n", + " \n", + "(&&) :: Bool -> Bool -> Bool\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And, on top of that, the binary operation is associative! Meaning the order in which we apply the binary function doesn't matter. And that's it! That's the whole concept:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + " A `Semigroup` is a type that has an associative binary operation." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "It seems like an arbitrary choice. Like, why this abstraction instead of another? Well, it'll be clear why at the end of the lesson. However, as with all the abstractions we'll cover in this course, it boils down to this: We realized they are more useful than others.\n", + "\n", + "Ok. So, now that we have the concept we want to represent and know that we need it to be available for multiple types, we'll create a type class that represents it. \n", + "\n", + "Aaand... this is it:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "class Semigroup a where\n", + " (<>) :: a -> a -> a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "I know, I know, a bit anti-climactic. All that hype for a two-line type class." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We chose to use an operator that looks like a diamond instead of a regular prefix function because the most common use case (as we saw in the examples we used to extract the pattern) is to apply the binary function as an infix function." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Now, wait a minute... what about the assosociativity? Where does that appear in the code? \n", + "\n", + "Well, the sad truth is that not even Haskell's type system, the most powerful of all general-purpose mainstream languages, can restrict this property. And, because we can not use code to transmit these requirements, we use laws written in plain text and kindly ask developers to follow them. Of course, developers follow them because these laws bring a lot of value.\n", + "\n", + "In this case, every time you create an instance of `Semigroup`, you have to make sure to satisfy the associativity law:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "**Associativity law:**\n", + "```haskell\n", + "x <> (y <> z) = (x <> y) <> z\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Ok, we have our abstraction ready. Let's implement an instance to see how that would look, starting with the list instance. \n", + "\n", + "We have to choose a binary operation. This is really easy for lists. If you explore the `Prelude` and the `Data.List` modules, or even easier, if you look up the type using Hoogle, you'll find out that there's only one operator that takes two lists to generate another list, and on top of that, it's associative! And that's the `++` operator that appends two lists:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(\"Abstract \" ++ \"me\") ++ \"!\" -- \"Abstract me!\"\n", + "\"Abstract \" ++ (\"me\" ++ \"!\") -- \"Abstract me!\"\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Awesome! We have our operator. And now, we can implement our instance. Just this time, I'll show all possible ways to do it. But, I trust that, by now, you could figure this out by yourself:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "instance Semigroup [a] where\n", + " (<>) = (++)\n", + "\n", + "-- same as doing:\n", + "\n", + "instance Semigroup [a] where\n", + " (<>) [] ys = ys\n", + " (<>) (x:xs) ys = x : xs <> ys\n", + " \n", + "-- same as doing:\n", + "\n", + "instance Semigroup [a] where\n", + " [] <> ys = ys\n", + " (x:xs) <> ys = x : xs <> ys\n", + " \n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "All three implementations are the same thing written differently, so you could choose whichever you want. In this case, because the operator is already defined, the best would be to just use it, as shown in the first implementation. And, if you're curious, that's how it's actually defined in the `base` library." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "To do a rough check that the associativity law holds, we could do a few tests by hand:" + ] + }, + { + "cell_type": "code", + "execution_count": 17, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "(\"is \" <> \"this \") <> \"True?\" == \"is \" <> (\"this \" <> \"True?\")\n", + "\n", + "(([1] <> [2]) <> []) <> [3,4] == [1] <> ([2] <> ([] <> [3,4]))\n", + "\n", + "([True] <> ([True] <> [False])) == [True] <> [True] <> [False]" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Of course, this is not proof that the law holds. It's just a suggestion that it seems to work, which is more than enough for us. However, thanks to Haskell's purity, we could prove this law by induction or property testing. That's out of the scope of this course, but I'll link an explanation in the video description. Just in case you're curious." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Ok, done! We have our first instance of `Semigroup`. It seems we're done with Semigroup, but there's one more thing to take into account: What if there's no clear answer as to which operation we should use? For example, if we're using numbers, a quick search would give us four binary operations:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(+) :: Num a => a -> a -> a\n", + "(*) :: Num a => a -> a -> a\n", + "(-) :: Num a => a -> a -> a\n", + "substract :: Num a => a -> a -> a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "But wait, if we quickly check of associativity:" + ] + }, + { + "cell_type": "code", + "execution_count": 18, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "9" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "9" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "24" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "24" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "-5" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "3" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "3" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "-1" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "(2 + 3) + 4 -- 9\n", + "2 + (3 + 4) -- 9 ✅\n", + "\n", + "(2 * 3) * 4 -- 24\n", + "2 * (3 * 4) -- 24 ✅\n", + "\n", + "(2 - 3) - 4 -- -5\n", + "2 - (3 - 4) -- 3 ❌\n", + "\n", + "(2 `subtract` 3) `subtract` 4 -- 3\n", + "2 `subtract` (3 `subtract` 4) -- -1 ❌" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We see that the `(-)` (minus) and `subtract` functions aren't associative. This makes sense because subtraction isn't associative in maths, either.\n", + "\n", + "So, we're left with just two functions:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(+) :: Num a => a -> a -> a\n", + "\n", + "(*) :: Num a => a -> a -> a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Which one should we use? Both functions satisfy the `Semigroup` requirements of being an associative binary function. But we can not choose more than one... or can we? " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "It turns out that some types, in this case, all numeric types, have more than one valid `Semigroup` instance. To resolve this, we create one `newtype` per valid and useful operation that wraps the original type. That way, we can implement as many instances as we need because they are different types!\n", + "\n", + "In the current case, because both the sum and product operations are valuable, we'll wrap a type in the `Sum` and `Product` `newtypes`:" + ] + }, + { + "cell_type": "code", + "execution_count": 19, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [], + "source": [ + "newtype Sum a = Sum { getSum :: a }\n", + " deriving (Show, Eq)\n", + "\n", + "newtype Product a = Product { getProduct :: a }\n", + " deriving (Show, Eq)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "As you can see, we just wrapped the `a` type with a `Sum` and `Product` constructors to get the new `Sum` and `Product` types. On top of that, we used record syntax to easily extract the wrapped value without the need for pattern-matching in case we want to.\n", + "\n", + "And now comes the magic. We'll implement their `Semigroup` instances using their corresponding binary operation:" + ] + }, + { + "cell_type": "code", + "execution_count": 20, + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [], + "source": [ + "instance Num a => Semigroup (Sum a) where\n", + " (Sum a) <> (Sum b) = Sum (a + b)\n", + "\n", + "instance Num a => Semigroup (Product a) where\n", + " (Product a) <> (Product b) = Product (a * b)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "As you can see, the only thing that changes is that we have to make sure the type inside `Sum` and `Product` are also instances of `Num` in order to have the `+` and `*` operators available to us.\n", + "\n", + "Other than that, it's just pattern-matching to unwrap the numbers from the parameters, applying the binary operation to the numbers, and wrapping the result.\n", + "\n", + "Let's try them!:" + ] + }, + { + "cell_type": "code", + "execution_count": 21, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Sum {getSum = 5}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Product {getProduct = 45}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "30" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "Sum 3 <> Sum 2\n", + "\n", + "Product 5 <> Product 9\n", + "\n", + "(Sum 4 <> Sum 5) <> Sum 1 == Sum 4 <> (Sum 5 <> Sum 1)\n", + "\n", + "getProduct $ Product 3 <> Product 5 <> Product 2\n", + "\n", + "-- Sum 9 <> Product 10 -- ❌ Won't compile! Different types!!" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "It works! This is not the only case. We also have two options between all the orderable types:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "max :: Ord a => a -> a -> a\n", + "\n", + "min :: Ord a => a -> a -> a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Both `max` and `min` functions are associative binary operations, and both make sense to use, so we do the same. We create `newtype` wrappers:" + ] + }, + { + "cell_type": "code", + "execution_count": 22, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [], + "source": [ + "newtype Max a = Max { getMax :: a }\n", + " deriving (Show, Eq)\n", + "\n", + "newtype Min a = Min { getMin :: a }\n", + " deriving (Show, Eq)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And then, we create the `Semigroup` instances with the corresponding associative binary operations:" + ] + }, + { + "cell_type": "code", + "execution_count": 23, + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [], + "source": [ + "instance Ord a => Semigroup (Max a) where\n", + " (Max a) <> (Max b) = Max (a `max` b)\n", + "\n", + "instance Ord a => Semigroup (Min a) where\n", + " (Min a) <> (Min b) = Min (a `min` b)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Finally, we test it:" + ] + }, + { + "cell_type": "code", + "execution_count": 24, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Min {getMin = 3}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Max {getMax = 9}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "5" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "Min 3 <> Min 6\n", + "\n", + "Max 9 <> Max 0\n", + "\n", + "(Min 4 <> Min 5) <> Min 1 == Min 4 <> (Min 5 <> Min 1)\n", + "\n", + "getMax $ Max 3 <> Max 5 <> Max 2" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The case for booleans is very similar; So similar that, in fact, you'll have to implement it as part of this lesson's homework.\n", + "\n", + "But before we move on, let's implement a `Semigroup` for a type we came up with ourselves. For example, the `Severity` type. A type that represents the severity of an emergency:" + ] + }, + { + "cell_type": "code", + "execution_count": 25, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [], + "source": [ + "data Severity = Low | Medium | High | Critical deriving (Show, Eq)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We don't have any pre-existent associative binary operations, so we'll have to come up with one. What do you think would be a good associative binary operation for severity?: " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "(<>) :: Severity -> Severity -> Severity\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Pause the video if you want to think about it for a bit. Better yet, try to implement it yourself!\n", + "\n", + "Ok. So, we want to combine severity levels. It makes sense that if we have two emergencies of the same severity, we should return one with the same severity. And if they are of different severities, we should return the highest one. So, we could define `Severity`'s `Semigroup` instance like this: " + ] + }, + { + "cell_type": "code", + "execution_count": 26, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [], + "source": [ + "instance Semigroup Severity where\n", + " Critical <> _ = Critical\n", + " _ <> Critical = Critical\n", + " High <> _ = High\n", + " _ <> High = High\n", + " Medium <> _ = Medium\n", + " _ <> Medium = Medium\n", + " _ <> _ = Low" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "I think this makes quite a lot of sense. Let's check if the binary operation is actually associative: " + ] + }, + { + "cell_type": "code", + "execution_count": 27, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "High" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Medium" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "High <> Medium\n", + "\n", + "Low <> Medium <> Low\n", + "\n", + "(High <> Low) <> Critical == High <> (Low <> Critical)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And that's it! We created our fifth `Semigroup` instance. If you understand everything up until now, the next abstraction will be a piece of cake. So, let's talk about the `Monoid` type class:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## The `Monoid` type class" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The `Monoid` type class builds on top of the `Semigroup` type class to add a small but significant extra behavior. Let's take a look at the same example we saw at the beginning, but with a slight tweak: " + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(\"Abstract \" ++ \"me\") ++ \"!\" -- \"Abstract me!\"\n", + "\"Abstract \" ++ \"\" ++ (\"me\" ++ \"!\") -- \"Abstract me!\"\n", + "\n", + "(2 * 3) * 4 -- 24\n", + "2 * 1 * (3 * 4) -- 24\n", + "\n", + "(True && False) && True -- False\n", + "True && True && (False && True) -- False\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Do you notice the changes I made in the code? And what about the changes in the result?\n", + "\n", + "As you can see, I added one more operation in the second line of each example, but it doesn't affect the end result because one of the values doesn't do anything. We call a value that doesn't modify the result: The \"Identity\" value. It's not the first time we encountered this concept. We first learned about identities when we learned about recursion and how vital identity values are in defining the base cases.\n", + "\n", + "And as you can see, the `1` is the identity for multiplication, the `True` is the identity for `&&`, and the empty string is the identity for concatenating `String`s, which, more generally speaking, means that the empty list is the identity of concatenating lists." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "So, if we speel it out, the pattern we're seeing right here is:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "A `Monoid` is a type that has an associative binary operation with an identity." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "But we already have a type class representing an associative binary operation. So, instead of repeating ourselves, we can make `Monoid` a subclass of `Semigroup` and add only the identity. Something like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "```haskell\n", + "class Semigroup a => Monoid a where\n", + " mempty :: a\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Here, the `mempty` value represents the identity. It's called like that due to convention. You can read it as `m` (from `Monoid`) `empty`. \n", + "\n", + "And this would be conceptually it. But, if we take a look at the actual `Monoid` type class in Haskell, it might look like this:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "class Semigroup a => Monoid a where\n", + " mempty :: a -- Identity element\n", + " mappend :: a -> a -> a -- <>\n", + " mconcat :: [a] -> a -- foldr <> mempty\n", + " {-# MINIMAL mempty | mconcat #-}\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And why is that? Why the extra functions?\n", + "\n", + "Well, because in previous versions of Haskell, we didn't have the `Semigroup` type class. The `Monoid` type class was self-contained, and needed to define its own associative binary operator. The \"monoid append\" or `mappend` function was the associative binary operation we defined in `Semigroup`, and the \"monoid concat\" or `mconcat` function is a behavior that we get for free thanks to having the `mempty` and `mappend` functions. It's just `foldr` applied to the binary operator and `mempty`." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "I say that it \"might look like this\" because, by the time you're watching this video, we might not have `mappend` in `Monoid` anymore since it's redundant now that we have `Semigroup`. \n", + "\n", + "We didn't remove `mappend` from `Monoid` when `Semigroup` was introduced because that would've broken virtually every program written in Haskell. So, to avoid receiving angry emails from every Haskell developer, the maintainers phased out the changes to give everyone the time to catch up before removing it." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Notice, however, that here it's happening the same as it happened with the associativity for `Semigroup`. The restriction that the `mempty` element has to be the identity of the operation is nowhere to be seen. We cannot enforce it with code, so we create laws that indicate to the developer that they have to adhere to some extra rules when implementing `Monoid` instances:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "**Right identity**\n", + "```haskell\n", + " x <> mempty = x -- e.g.: Sum 4 <> Sum 0 == Sum 4\n", + "```\n", + "**Left identity**\n", + "```haskell\n", + " mempty <> x = x -- e.g.: Sum 0 <> Sum 4 == Sum 4 \n", + "```\n", + "**Associativity**\n", + "```haskell\n", + " x <> (y <> z) = (x <> y) <> z -- (Semigroup law)\n", + "```\n", + "**Concatenation**\n", + "```haskell\n", + " mconcat = foldr (<>) mempty\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Ok! Let's implement a few `Monoid` Instances.\n", + "\n", + "This is actually pretty easy because we did the hard part when implementing the `Semigroup` type class. These are the `Monoid` instances of all the types we worked with today:" + ] + }, + { + "cell_type": "code", + "execution_count": 29, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [], + "source": [ + "--instance Monoid [a] where\n", + "-- mempty = []\n", + "\n", + "instance Num a => Monoid (Sum a) where\n", + " mempty = Sum 0\n", + "\n", + "instance Num a => Monoid (Product a) where\n", + " mempty = Product 1\n", + "\n", + "instance (Ord a, Bounded a) => Monoid (Max a) where\n", + " mempty = Max minBound\n", + "\n", + "instance (Ord a, Bounded a) => Monoid (Min a) where\n", + " mempty = Min maxBound\n", + "\n", + "instance Monoid Severity where\n", + " mempty = Low" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "As you can see, all of the instances are pretty straightforward. You have to think of the value that doesn't change the result when applied to the `Semigroup`'s associative binary operation.\n", + "\n", + "- If you sum `0` to a value, you get the same initial value.\n", + "- If you multiply a value by `1`, you get the same initial value.\n", + "- If you compare if a value is greater than the smallest possible value, you get the same initial value.\n", + "- If you compare if a value is smaller than the largest possible value, you get the same initial value.\n", + "- If you combine any severity with the lowest one, you get the same initial severity.\n", + "\n", + "Here are a few examples:" + ] + }, + { + "cell_type": "code", + "execution_count": 16, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Max {getMax = -9223372036854775808}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Max {getMax = 3}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Min {getMin = 9223372036854775807}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Min {getMin = 2}" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Medium" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "True" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "Sum 2 <> mempty <> Sum 3 == Sum 2 <> Sum 3 -- True\n", + "\n", + "mconcat [Product 2, Product 3, mempty] == Product 2 <> Product 3 -- True\n", + "\n", + "(mempty) :: Max Int -- Max {getMax = -9223372036854775808}\n", + "\n", + "Max 2 <> mempty <> Max 3 :: Max Int -- Max {getMax = 3}\n", + "\n", + "(mempty) :: Min Int -- Min {getMin = 9223372036854775807}\n", + "\n", + "mempty <> Min 2 <> mempty :: Min Int -- Min {getMin = 2}\n", + "\n", + "mconcat [mempty, Medium, mempty, mempty] -- Medium\n", + "\n", + "Sum 9 <> Sum 11 == Sum 9 `mappend` Sum 11 -- True" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And that's it! We created our first 5 instances of `Monoid`.\n", + "\n", + "Now that we know about `Semigroup` and `Monoid`, let's answer the big question. Why are they useful?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## What can I do with `Semigroup` and `Monoid`?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We already established that by abstracting patterns, you can more easily reduce code, hide implementation details that aren't part of the core logic, and have clear and concise code that you (and others) can quickly understand. But that's for all abstractions in general. What do I gain with `Semigroup` and `Monoid` specifically?" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "### Distributed computation" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "notes" + } + }, + "source": [ + "Imagine you have a dataset of stars with various data points: Their size, mass, brightness, etc. And we want to know which one is the oldest.\n", + "\n", + "We cannot measure the age of a star, so we have to calculate it with a formula that takes all the data of a star and returns its approximate age.\n", + "\n", + "If that computation takes 1 second, and we have a dataset of 1000 stars, it would take around 17 minutes to complete. Not a big deal.\n", + "\n", + "But... that's not a realistic number of stars. Gaia, one of the European Space Agency's telescopes, is currently taking precise measurements of close to 1 billion of the brightest stars in the sky. That's too big of a number to wrap our heads around, so let's say we get our hands on a dataset of 1 million stars. If you want to run your function on that dataset, it will take 114 years to complete. You'll likely be dead before that finishes.\n", + "\n", + "If only there was a way to reduce the wait time..." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "source": [ + "
![](\"../images/distributed_computation.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Well, if the result of an `IO` computation is a `Monoid`, the `IO` computation is a `Monoid` too!! This means you could wrap the computation's result with the `Max` monoid, split the work into 200 servers that run in parallel, and merge the results as soon as two consecutive servers finish their computation.\n",
+ "\n",
+ "The end result? Instead of waiting 114 years, you have to wait only 6 months. 0.5% of the time it would take using a single server. And, of course, you could keep reducing the wait by spinning more servers."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, this feat could be accomplished without a `Semigroup` or `Monoid` instance. But having them made it waaaaay easier. So much easier, in fact, that we didn't have to change the computation!! We just wrapped the result with the `Max` constructor and called it a day. We changed 1 line of code to make our computation parallelizable."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Scaling result complexity without increasing code complexity"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Let's say we have a social media app with a form that a user has to complete with their personal information to create their account:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_1.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The user asks to be able to configure their experience, so we add a settings page tha its just a another form:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_2.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "After some time, we add a form to change their profile image. We need to add this to the settings. But also inside the one to create an account. So we created a reusable component and put it inside both:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_3.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Companies also want to use our app, so we added a form for company settings that also has to be inside the one to open the account:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_4.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Of course, people lose their passwords, so we'll create a reusable form to change our password that we'll put inside the regular user and company settings: "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_5.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Ok, I think that's enough, you get the idea. This is not only about forms. It's the conventional architecture most programs follow:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "Combine several components of type `A` to generate a \"network\" or \"structure\" of a different type `B`."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "That means that every time we add something that generates a more complex end-user experience, the complexity of our code exponentially increases because we have to not only create the new component but also integrate it into the system. And with each addition, it gets harder and harder."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, what if the forms themselves where `Semigroup`s? In that case, we don't need to worry about integrating them since that's done by our associative binary operation:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "![](\"../images/monoid_form_6.png\"\n",)
"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "We combine several components of type `A` to generate a new one of the same type `A`."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So, if I want to add a new form now, it doesn't matter if we already have 1, 10, or 100 forms. The complexity is always the same. You still have to build the new form, but you get the integration for free."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Those are two fairly obvious ways that `Semigroup` and `Monoid` instances help. If you want more examples, you'll have to do the homework.\n",
+ "\n",
+ "And if you're thinking: \"Why did we need to separate `Semigroup` and `Monoid` again? Can't we just have `Monoid` and that's it?\"\n",
+ "\n",
+ "`Monoid` is more powerful than `Semigroup` because the identity element allows for an easy way to fold and concatenate the elements. So, based on what we know now, it would make sense to only have the `Monoid` type class. But here's the thing: Some types can be instances of `Semigroup` but not of `Monoid`, and it doesn't make sense we have to lose most of the power just because they don't have an identity element. \n",
+ "\n",
+ "For example, there's a type in Haskell that represents a list that can never be empty. And because of that, it doesn't have an identity element and can never be a `Monoid`! Curious about how that works? Well..."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "# That's it for today!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Do your homework to find out, and I'll see you in the next one!"
+ ]
+ }
+ ],
+ "metadata": {
+ "celltoolbar": "Slideshow",
+ "kernelspec": {
+ "display_name": "Haskell",
+ "language": "haskell",
+ "name": "haskell"
+ },
+ "language_info": {
+ "codemirror_mode": "ihaskell",
+ "file_extension": ".hs",
+ "mimetype": "text/x-haskell",
+ "name": "haskell",
+ "pygments_lexer": "Haskell",
+ "version": "8.10.7"
+ }
+ },
+ "nbformat": 4,
+ "nbformat_minor": 4
+}
diff --git a/lessons/18-Functor.ipynb b/lessons/18-Functor.ipynb
new file mode 100644
index 00000000..cdac454c
--- /dev/null
+++ b/lessons/18-Functor.ipynb
@@ -0,0 +1,6785 @@
+{
+ "cells": [
+ {
+ "cell_type": "code",
+ "execution_count": 1,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "outputs": [],
+ "source": [
+ ":opt no-lint"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "# Functor"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Welcome to a new lesson of the Haskell curse. This one is all about the `Functor` type class."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "### Functors are 🌏 EVERYWHERE!! 🌎\n",
+ "\n",
+ "In this lesson:\n",
+ "- You'll understand the concept of `Functor`\n",
+ "- You'll learn everything you need to know to use them in practice."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We have Functors in mathematics, programming languages, linguistics, under your bed waiting for you to go to sleep... Functors are everywhere!! You might have worked with functors without even knowing.\n",
+ "\n",
+ "After this lesson, you will not only understand the concept of `Functor` in Haskell, but we'll also go the extra mile so you can learn everything you need to know to actually use it in practice.\n",
+ "\n",
+ "And how are we going to do that? This is how:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Outline\n",
+ "\n",
+ "* Abstracting the `map` function\n",
+ "* The `Functor` type class\n",
+ "* Defining `Functor` instances\n",
+ "* Seemingly unintuitive `Functor` instances\n",
+ " * The `Either a` functor 🤔\n",
+ " * The `(,) a` functor 🤨\n",
+ " * The `(->) r` functor 🤯\n",
+ "* Defining `<$>` and Lifting 🏋️ a function\n",
+ "* `Functor` nesting dolls 🪆\n",
+ "* Extra functions and `Functor` as defined in `base`"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Abstracting the `map` function"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This chapter will be super easy since you already know about `map`. Let's implement a function that returns the lower-case version of a String:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 2,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "\"hi, how's it going?\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "import Data.Char (toLower)\n",
+ "\n",
+ "lowerString :: [Char] -> [Char]\n",
+ "lowerString [] = []\n",
+ "lowerString (x:xs) = toLower x : lowerString xs\n",
+ "\n",
+ "lowerString \"Hi, How's it Going?\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, let's implement a function that adds one to a list of numbers:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 3,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[2,2,3,4]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "addOne :: Num a => [a] -> [a]\n",
+ "addOne [] = []\n",
+ "addOne (x:xs) = (x + 1) : addOne xs\n",
+ "\n",
+ "addOne [1,1,2,3]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And now, let's implement a function that transforms a list of boolean values to a list of characters representing bits:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 4,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "\"101\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "boolToBit :: [Bool] -> [Char]\n",
+ "boolToBit [] = []\n",
+ "boolToBit (x:xs) = (if x then '1' else '0') : boolToBit xs\n",
+ "\n",
+ "boolToBit [True,False,True]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Ok. So, I'm sure you see where I'm going with this. There's a repeating pattern, so we'll extract it into its own function.\n",
+ "\n",
+ "Let's start with the type. As input, we have a list of characters, a list of types that are instances of the `Num` type class, and a list of booleans. So, the most general type would be `[a]` (a list of `a`) for the input list. \n",
+ "\n",
+ "As output type, at first glance, we could use the same `[a]`, but as we see in the `boolToBit` function, there are cases when you return a list with values of different types. So, there's no need to add an extra restriction to have the same type for the list that goes in and the one that goes out. So, let's use a different variable, like `[b]`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "map :: [a] -> [b]\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, let's extract the pattern:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "map [] = []\n",
+ "map (x:xs) = f x : map xs\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This looks mostly ok. But we have to get the function `f` from somewhere, so we add it as a parameter. And, because the function `f` takes a value of type `a` from the input list and generates a value of type `b` from the output list, it follows that the function's type is `a -> b`. So, the final expression of our abstraction looks like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 5,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "\"hi, how's it going?\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,2,3,4]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"101\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "map :: (a -> b) -> [a] -> [b]\n",
+ "map _ [] = []\n",
+ "map f (x:xs) = f x : map f xs\n",
+ "\n",
+ "\n",
+ "map toLower \"Hi, How's it Going?\"\n",
+ "\n",
+ "map (+1) [1,1,2,3]\n",
+ "\n",
+ "map (\\x -> if x then '1' else '0') [True,False,True]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Awesome! We abstracted away the concept of applying an arbitrary function to every value of a list, and we called this abstraction a \"map.\" Then, we used this function to avoid repeating ourselves and simplify our code. This is cool, but we can do better. Let's go one level higher with the `Functor` type class:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Abstracting the `Functor` Type Class"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In Haskell, we have lots of types. So, let's say we're working with optional values using the `Maybe` type. Same as with lists, we also need a way to conveniently modify values inside `Maybe` types. No biggy, we know the drill. We can define the `maybeMap` function:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 6,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Just 'a'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just '1'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Nothing"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Nothing"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Nothing"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "maybeMap :: (a -> b) -> Maybe a -> Maybe b\n",
+ "maybeMap _ Nothing = Nothing\n",
+ "maybeMap f (Just x) = Just (f x)\n",
+ "\n",
+ "\n",
+ "maybeMap toLower (Just 'A')\n",
+ "\n",
+ "maybeMap (+1) (Just 3)\n",
+ "\n",
+ "maybeMap (\\x -> if x then '1' else '0') (Just True)\n",
+ "\n",
+ "\n",
+ "maybeMap toLower Nothing\n",
+ "\n",
+ "maybeMap (+1) Nothing\n",
+ "\n",
+ "maybeMap (\\x -> if x then '1' else '0') Nothing"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, the `maybeMap` function can't do anything when the `Maybe` value is `Nothing`. This makes sense: Something went wrong before the value arrived at this function, so we should propagate the error. But, when we have a value, we apply the function to the value and wrap it again in a `Just` constructor."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Notice how the function we apply as the first parameter in both `map` and `maybeMap` is oblivious to the structure that contains the value it modifies. This is important because it means we could use the same functions in both cases and let `map` and `maybeMap` handle the details."
+ ]
+ },
+ {
+ "cell_type": "raw",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "OK. Let's do a harder one. Let's say we want to work with binary trees:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 7,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 2) 1 (Node (Leaf 4) 3 (Leaf 5))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "data Tree a = Leaf a | Node (Tree a) a (Tree a) deriving (Show, Eq)\n",
+ "\n",
+ "\n",
+ "exampleTree = Node (Leaf 2) 1 (Node (Leaf 4) 3 (Leaf 5))\n",
+ "exampleTree\n",
+ "\n",
+ "\n",
+ "-- 1\n",
+ "-- / \\\n",
+ "-- 2 3\n",
+ "-- / \\\n",
+ "-- 4 5"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Now, I can think of many scenarios that involve modifying the values of each node and leaf without changing the structure of the tree. Maybe the tree represents a family tree, and each number is the age of a family member. After one year passes, we have to update the ages of everyone by one. Or maybe it represents the hierarchical structure of positions in a company, and we have to update the salaries by some percentage to account for inflation.\n",
+ "\n",
+ "Either way, we need to apply a function to the values without losing the structure. Same as we did for lists and `Maybe` values. So, we create `treeMap`:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 8,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 'b') 'a' (Node (Leaf 'd') 'c' (Leaf 'e'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 3) 2 (Node (Leaf 5) 4 (Leaf 6))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf '0') '1' (Node (Leaf '0') '1' (Leaf '1'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "treeMap :: (a -> b) -> Tree a -> Tree b\n",
+ "treeMap f (Leaf x) = Leaf (f x)\n",
+ "treeMap f (Node lt x rt) = Node (treeMap f lt) (f x) (treeMap f rt)\n",
+ "\n",
+ "\n",
+ "treeMap toLower (Node (Leaf 'B') 'A' (Node (Leaf 'D') 'C'(Leaf 'E')))\n",
+ "\n",
+ "treeMap (+1) (Node (Leaf 2) 1 (Node (Leaf 4) 3 (Leaf 5)))\n",
+ "\n",
+ "treeMap (\\x -> if x then '1' else '0') (Node (Leaf False) True (Node (Leaf False) True (Leaf True)))"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "If it's a `Leaf`, `treeMap` applies the function to the current value. And if it's a `Node`, `treeMap` also applies the function to the current value and recursively calls `treeMap` on both branches."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, a new pattern is emerging:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "map :: (a -> b) -> [a] -> [b]\n",
+ "map _ [] = []\n",
+ "map f (x:xs) = f x : map f xs\n",
+ "\n",
+ "\n",
+ "\n",
+ "maybeMap :: (a -> b) -> Maybe a -> Maybe b\n",
+ "maybeMap _ Nothing = Nothing\n",
+ "maybeMap f (Just x) = Just (f x)\n",
+ "\n",
+ "\n",
+ "\n",
+ "treeMap :: (a -> b) -> Tree a -> Tree b\n",
+ "treeMap f (Leaf x) = Leaf (f x)\n",
+ "treeMap f (Node lt x rt) = Node (treeMap f lt) (f x) (treeMap f rt)\n",
+ "\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "- The `map` function modifies the elements of a list without changing its length or order.\n",
+ "- The `maybeMap` modifies the elements of an optional value without changing its nature. It returns `Nothing` if the original value is `Nothing` and `Just` if it's `Just`.\n",
+ "- The `treeMap` function modifies the elements of a tree without changing the amount and arrangement of nodes and leaves.\n",
+ "\n",
+ "In all cases we apply a function to a value or values inside a structure without modifying the structure itself."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This seems like an extremely valuable abstraction, so let's extract it.\n",
+ "\n",
+ "To extract `map`, we had to generalize the types of values inside the lists and the function we applied. Because that was what changed between examples.\n",
+ "\n",
+ "Now, the thing that changes is the structure that holds these values, which, here, is represented by the list, `Maybe`, and `Tree` types. So, we have to provide this abstraction as a type class that types could implement. We'll call this type class `Functor` because of math terminology, but that doesn't change what the abstraction means to us.\n",
+ "\n",
+ "So, what is a `Functor` in Haskell?"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "A `Functor` is a type that can apply a function to the values of a structure without modifying the structure itself."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We need only one behavior, the function that does the mapping. If we look at the `map`, `maybeMap`, and `treeMap` functions, we see that the first parameter, the function, is always the same. This makes sense since we said before that we wanted the functions to be independent of the structure. Then, the second and third parameters are always structures of `a`s that become structures of `b`s. So, the type is almost there, we just need to generalize the structure itself. And that's how we obtain the type class definition:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "class Functor f where\n",
+ " fmap :: (a -> b) -> f a -> f b\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The `fmap` (or \"functor map\") function takes a function that goes from `a` to `b` and a structure `f` containing elements of type `a`, and applies the function to the elements to return the same structure `f` but with elements of type `b`."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "If, for some reason, having polymorphic type constructors such as `f` doesn't feel intuitive, we'll talk more about it when creating instances. But I'd still recommend you revisit lesson 10 (\"Creating Type Classes and Instances\"), where we discuss this subject in depth and define several type classes with increasing levels of complexity.\n",
+ "\n",
+ "Ok. So, we have our `Functor` type class. But this is not over. We also have the requirement to avoid `fmap` changing the structure. What would that look like, though? Well, let's implement `fmap` for lists the wrong way:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 9,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "[2,3,4]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,2,3,3,4,4]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[1,2,3]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[1,1,1,1,2,2,2,2,3,3,3,3]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "-- map :: (a -> b) -> [a] -> [b]\n",
+ "-- map _ [] = []\n",
+ "-- map f (x:xs) = f x : map f xs\n",
+ "\n",
+ "wrongFmap :: (a -> b) -> [a] -> [b]\n",
+ "wrongFmap _ [] = []\n",
+ "wrongFmap f (x:xs) = f x : f x : wrongFmap f xs\n",
+ "\n",
+ "map (+1) [1,2,3]\n",
+ "wrongFmap (+1) [1,2,3]\n",
+ "\n",
+ "(map (\\x -> x - 1)) . (map (+1)) $ [1,2,3]\n",
+ "(wrongFmap (\\x -> x - 1)) . (wrongFmap (+1)) $ [1,2,3]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "If the structure doesn't change, we should get the original value if we apply a function and then apply the inverse. In this example, we first add one and then subtract one. In both cases, the types are correct. And we do get the original list using `map`. But because the `wrongMap` implementation concatenates each value twice, we get a completely new list instead of the original one!\n",
+ "\n",
+ "An easier way to test this, however, would be with a function that doesn't do anything. That way, if we apply `fmap` to that function, we know we should get the same result as if we didn't do anything. Haskell has that function, and it's called `id` for identity:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 10,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "False"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"HHeelllloo!!\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "-- id x = x\n",
+ "\n",
+ "id 3 == 3\n",
+ "\n",
+ "id [1,2,3] == [1,2,3] -- Apply id to the whole list\n",
+ "\n",
+ "map id \"Hello!\" == \"Hello!\" -- Apply id to every element of the list\n",
+ "\n",
+ "wrongFmap id \"Hello!\" == \"Hello!\"\n",
+ "\n",
+ "wrongFmap id \"Hello!\""
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Same as with `Semigroup` and `Monoid`, since we can't enforce this property through the type system, we'll define a law using this `id` function and ask developers to pretty-please follow it:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Identity law**\n",
+ "```haskell\n",
+ "fmap id == id\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This basically means: \"If you apply the identity function to every element of a structure using `fmap`, it should be the same as applying the identity function to the whole structure.\"\n",
+ "\n",
+ "Because you have to return the same value and the `id` function is only concerned about the values inside your structure, you're forced to implement `fmap` in a way that maintains the structure.\n",
+ "\n",
+ "This is it for this law. One itsy bitsy thing I didn't tell you, though, is that we have a second law. But before you feel betrayed, let me say you don't need to worry about this law! And I'll tell you why. Here's the composition law:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "**Composition law**\n",
+ "```haskell\n",
+ "fmap (f . g) == fmap f . fmap g\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This law states that if you apply the composition of two functions to the elements of a structure using `fmap`, you have to get the same result as if you `fmap` one function and then `fmap` the other.\n",
+ "\n",
+ "This is obviously an important property since we use function composition everywhere. But the cool thing is that you don't have to check for this law when defining your instance! Thanks to Haskell's type system, if you follow the identity law, you also implicitly follow the composition law!! We could prove that using equational reasoning, but it falls out of the scope of the course, so I'll leave a link in the description for the curious ones."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Ok. So, our final type class looks like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "class Functor f where\n",
+ " fmap :: (a -> b) -> f a -> f b\n",
+ "\n",
+ "\n",
+ "```\n",
+ "**Identity law**\n",
+ "```haskell\n",
+ "fmap id == id\n",
+ "```\n",
+ "**Composition law**\n",
+ "```haskell\n",
+ "fmap (f . g) == fmap f . fmap g\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's it! This is what `Functor` is about. \n",
+ "\n",
+ "Some explanations present functors as containers of values. Others, as values that have context. You can think of it however you want. The bottom line is that any type that is an instance of the Functor type class and follows the Functor's laws is a `Functor`.\n",
+ "\n",
+ "And since we already have our type class, let's define some instances!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Defining `Functor` instances "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "First, let's review the type class kind:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 11,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "Eq :: * -> Constraint"
+ ],
+ "text/plain": [
+ "Eq :: * -> Constraint"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "Ord :: * -> Constraint"
+ ],
+ "text/plain": [
+ "Ord :: * -> Constraint"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "Functor :: (* -> *) -> Constraint"
+ ],
+ "text/plain": [
+ "Functor :: (* -> *) -> Constraint"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k Eq\n",
+ ":k Ord\n",
+ ":k Functor"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Unlike `Eq`, `Ord`, and most other type classes we worked with before, `Functor` takes a type constructor of a kind star to star instead of a concrete type. \n",
+ "\n",
+ "This means that you can create instances of `Functor` only for type constructors that take one concrete type. Let's see how that looks in practice for the `Maybe` type:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "Maybe -- * -> *\n",
+ "Maybe a -- * \n",
+ "\n",
+ "instance Eq a => Eq (Maybe a) where -- ✅\n",
+ "\n",
+ "instance Ord a => Ord (Maybe a) where -- ✅\n",
+ "\n",
+ "instance Functor a => Functor (Maybe a) where -- ❌\n",
+ "\n",
+ "instance Functor Maybe where -- ✅\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, for `Eq` and `Ord`, we need to apply `Maybe` to the type variable `a` to get the correct kind. But it is not necessary for `Functor`.\n",
+ "\n",
+ "Same with lists:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "[] -- * -> *\n",
+ "[a] -- * \n",
+ "\n",
+ "instance Eq a => Eq [a] where -- ✅\n",
+ " ...\n",
+ "\n",
+ "instance Ord a => Ord [a] where -- ✅\n",
+ " ...\n",
+ "\n",
+ "instance Functor a => Functor [a] where -- ❌\n",
+ " ...\n",
+ " \n",
+ "instance Functor [] where -- ✅\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And, as we saw on lesson 10, if you have a constructor that requires more than one concrete type, you can partially apply it:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "data Present t a = Empty t | PresentFor t a\n",
+ "\n",
+ "Present -- * -> * -> *\n",
+ "Present t -- * -> *\n",
+ "Present t a -- *\n",
+ "\n",
+ "-----------------------------------------------------------------------\n",
+ "\n",
+ "instance (Eq t, Eq a) => Eq (Present t a) where -- ✅\n",
+ " ...\n",
+ "\n",
+ "instance (Ord t, Ord a) => Ord (Present t a) where -- ✅\n",
+ " ...\n",
+ "\n",
+ "instance (Functor t, Functor a) => Functor (Present t a) where -- ❌\n",
+ " ...\n",
+ "\n",
+ "instance Functor (Present t) where -- ✅\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "If you're not 100% clear on this, revisit lesson 10. If you are, let's define some instances!:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "-- class Functor f where\n",
+ "-- fmap :: (a -> b) -> f a -> f b\n",
+ " \n",
+ " \n",
+ "instance Functor [] where\n",
+ " -- fmap :: (a -> b) -> [a] -> [b]\n",
+ " fmap _ [] = []\n",
+ " fmap f (x:xs) = f x : fmap f xs\n",
+ "\n",
+ "\n",
+ "instance Functor Maybe where\n",
+ " -- fmap :: (a -> b) -> Maybe a -> Maybe b\n",
+ " fmap _ Nothing = Nothing\n",
+ " fmap f (Just x) = Just (f x)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "These are the `Functor` instances for lists and `Maybe` types. I added the specialized type as a comment to help you visualize what's going on.\n",
+ "\n",
+ "We don't run this cell because these instances are already present in the Prelude. But we can create one that it isn't:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 12,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "instance Functor Tree where\n",
+ " -- fmap :: (a -> b) -> Tree a -> Tree b\n",
+ " fmap f (Leaf x) = Leaf (f x)\n",
+ " fmap f (Node lt x rt) = Node (fmap f lt) (f x) (fmap f rt)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, the implementations are the same functions we previously had implemented as separate versions of `map`. So, no surprise there.\n",
+ "\n",
+ "We, however, now want to check if they work as expected and follow the identity law, so let's do that:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 13,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "\"010\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just '1'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf '0') '1' (Node (Leaf '0') '1' (Leaf '1'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "boolToBit :: Bool -> Char\n",
+ "boolToBit x = if x then '1' else '0'\n",
+ "\n",
+ "exampleTree = Node (Leaf False) True (Node (Leaf False) True (Leaf True))\n",
+ "\n",
+ "fmap boolToBit [False,True,False]\n",
+ "\n",
+ "fmap boolToBit (Just True)\n",
+ "\n",
+ "fmap boolToBit exampleTree\n",
+ "\n",
+ "fmap id [1,2,3] == id [1,2,3]\n",
+ "\n",
+ "fmap id (Just 'c') == id (Just 'c')\n",
+ "\n",
+ "fmap id exampleTree == id exampleTree"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And those were our first three Functors in action. If you made it up until here, you learned what Functors are. But stay with me because there are a few practical aspects that you should really know about."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Seemingly unintuitive `Functor` instances"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "A few `Functor` instances seem unintuitive at first, and many new Haskell developers struggle to make sense of them. As part of my effort to give you the whole picture, let's explore them."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### The `Either a` functor 🤔"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The `Either` type constructor that takes two concrete types:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 14,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "Either :: * -> * -> *"
+ ],
+ "text/plain": [
+ "Either :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "Either String :: * -> *"
+ ],
+ "text/plain": [
+ "Either String :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k Either\n",
+ ":k Either String"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So, to create a `Functor` instance, we have to partially apply one type variable:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor (Either a) where\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We could interpret this as the error value of type `a` being (quote and quote) \"part of the structure\" of the functor. This means that values of type `a` should be kept untouched since `fmap` has to preserve the structure.\n",
+ "\n",
+ "So, the instance of `Functor` for `Either a` is:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor (Either a) where\n",
+ " fmap _ (Left x) = Left x\n",
+ " fmap f (Right y) = Right (f y)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Which is virtually the same instance as `Maybe`. We ignore the failure case and only apply the function in the success scenario.\n",
+ "\n",
+ "Here are some examples:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 15,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Left 1"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Right 2"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Left 'A'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "fmap (+1) (Left 1)\n",
+ "\n",
+ "fmap (+1) (Right 1)\n",
+ "\n",
+ "fmap toLower (Left 'A')\n",
+ "\n",
+ "fmap id (Left 'A') == id (Left 'A')\n",
+ "\n",
+ "fmap id (Right 'A') == id (Right 'A')"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Wasn't that hard, right? Let's keep going."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### The `(,) a` functor 🤨"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "These are tuples:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 16,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "('c', True) :: (Char, Bool)"
+ ],
+ "text/plain": [
+ "('c', True) :: (Char, Bool)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(True, 'c') :: (Bool, Char)"
+ ],
+ "text/plain": [
+ "(True, 'c') :: (Bool, Char)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "('c', True, 1 :: Int) :: (Char, Bool, Int)"
+ ],
+ "text/plain": [
+ "('c', True, 1 :: Int) :: (Char, Bool, Int)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":t ('c', True)\n",
+ "\n",
+ ":t (True, 'c')\n",
+ "\n",
+ ":t ('c', True, 1 :: Int)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We already discussed in a previous lesson that the type of the tuple, unlike lists, depends on the amount and order of its values. If we ask the kind of all those tuples, of course, we get concrete types:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 17,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "(Char, Bool) :: *"
+ ],
+ "text/plain": [
+ "(Char, Bool) :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(Bool, Char) :: *"
+ ],
+ "text/plain": [
+ "(Bool, Char) :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(Char, Bool, Int) :: *"
+ ],
+ "text/plain": [
+ "(Char, Bool, Int) :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "[Int] :: *"
+ ],
+ "text/plain": [
+ "[Int] :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "[] :: * -> *"
+ ],
+ "text/plain": [
+ "[] :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k (Char, Bool)\n",
+ ":k (Bool, Char)\n",
+ ":k (Char, Bool, Int)\n",
+ "\n",
+ ":k [Int]\n",
+ ":k []"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "But these types are just parentheses with commas that surround other types. So, could we remove the types to get a type constructor like we do with lists? Yes, we can! Because parentheses with commas are value constructors at the value level and type constructors at the type level."
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 19,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "(,) :: * -> * -> *"
+ ],
+ "text/plain": [
+ "(,) :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(,,) :: * -> * -> * -> *"
+ ],
+ "text/plain": [
+ "(,,) :: * -> * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(,) Int :: * -> *"
+ ],
+ "text/plain": [
+ "(,) Int :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(,,) String Bool :: * -> *"
+ ],
+ "text/plain": [
+ "(,,) String Bool :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k (,)\n",
+ ":k (,,)\n",
+ "\n",
+ "\n",
+ ":k (,) Int -- :k (a,) doesn't work. No sugar for tuples.\n",
+ ":k (,,) String Bool "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "These are just type constructors that take other types to create a concrete type. Tuples don't have the nice syntactic sugar that lists have, so we have to write first the constructor and then the type variables instead of having the type variables inside.\n",
+ " \n",
+ "Based on this, we can create `Functor` instances for tuples as long as we partially apply type variables to get a kind star to star:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "\n",
+ "instance Functor ((,) a) where\n",
+ " ...\n",
+ "\n",
+ "instance Functor ((,,) a b) where\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So, we have our types. How should we implement these instances? Well, we don't have much of a choice. For the pair, the first value of type `a` is part of the structure we can't touch, and for the tuple of three values, the first two values of type `a` and `b` are part of the structure. So, we can't touch either of those.\n",
+ "\n",
+ "At the end of the day, the most obvious and straightforward definitions would be these ones:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor ((,) a) where\n",
+ " fmap f (x,y) = (x, f y)\n",
+ "\n",
+ "\n",
+ "instance Functor ((,,) a b) where\n",
+ " fmap f (x,y,z) = (x, y, f z)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This is sometimes unintuitive because you would assume that we should apply the function to all values, the same as lists. But the key here is to think in terms of value and structure.\n",
+ "\n",
+ "The values of the lists are all the elements it contains, and the structure is the order and number of elements.\n",
+ "\n",
+ "The case of tuples is different. For tuples, all the values except for the last one are part of the structure, as evidenced by the type we create the instance for. So, the only thing we can modify is the one value we don't provide a type variable for.\n",
+ "\n",
+ "Let's test our instances:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 20,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "(1,2)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "('a',2)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "(True,'a',4)"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "('A','b')"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "(1,'b')"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "(2,True,'a')"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "fmap (+1) (1,1)\n",
+ "\n",
+ "fmap (+1) ('a',1)\n",
+ "\n",
+ "fmap (*2) (True,'a',2)\n",
+ "\n",
+ "fmap toLower ('A','B')\n",
+ "\n",
+ "fmap toLower (1,'B')\n",
+ "\n",
+ "fmap toLower (2, True, 'A')\n",
+ "\n",
+ "fmap id ('a',1 ) == id ('a',1 )\n",
+ "\n",
+ "fmap id (2, True, 'A') == id (2, True, 'A')"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "### The `(->) r` functor 🤯"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This might blow your mind, but I have to say it... functions are functors! Hear me out. "
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 21,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "(Char, Bool) :: *"
+ ],
+ "text/plain": [
+ "(Char, Bool) :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(,) :: * -> * -> *"
+ ],
+ "text/plain": [
+ "(,) :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "biggerThan3 :: Int -> Bool"
+ ],
+ "text/plain": [
+ "biggerThan3 :: Int -> Bool"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(Int -> Bool) :: *"
+ ],
+ "text/plain": [
+ "(Int -> Bool) :: *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(->) :: * -> * -> *"
+ ],
+ "text/plain": [
+ "(->) :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k (Char, Bool)\n",
+ ":k (,)\n",
+ "\n",
+ "biggerThan3 :: Int -> Bool\n",
+ "biggerThan3 = (>3)\n",
+ "\n",
+ ":t biggerThan3\n",
+ ":k (Int -> Bool)\n",
+ "\n",
+ ":k (->)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "The arrow we use to define the type signatures of functions is a type constructor. This type constructor takes two concrete types and returns a concrete type. \n",
+ "\n",
+ "Same as when we give two types like `Char` and `Bool` to the pair type constructor to get the type of a pair containing a character and a boolean if we give two types like `Int` and `Bool` to the arrow type constructor, we get the type of a function that takes an `Int` and returns a `Bool`. "
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So, guess what. We can do with the arrow constructor the same we did for pairs to create the `Functor` instance. We'll partially apply a type variable:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 22,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "(,) :: * -> * -> *"
+ ],
+ "text/plain": [
+ "(,) :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(,) Int :: * -> *"
+ ],
+ "text/plain": [
+ "(,) Int :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(->) :: * -> * -> *"
+ ],
+ "text/plain": [
+ "(->) :: * -> * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(->) Int :: * -> *"
+ ],
+ "text/plain": [
+ "(->) Int :: * -> *"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":k (,) -- ❌\n",
+ ":k (,) Int -- Functastic! ✅\n",
+ "\n",
+ ":k (->) -- ❌\n",
+ ":k (->) Int -- Functastic! ✅"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We also don't have syntactic sugar in this case. So, our `Functor` instance would start like this:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor ((->) r) where\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Remember that the `r` is the first type we apply the constructor to. So, it's the input type of the function.\n",
+ "\n",
+ "Now, I'm aware this type is a bit overwhelming the first time you encounter it, so let's work our way through it. This is the type of `fmap`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "fmap :: (a -> b) -> f a -> f b\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In this particular instance of `fmap`, the Functor `f` is the arrow applied to a type variable:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "fmap :: (a -> b) -> (->) r a -> (->) r b -- Specialize f to (->) r\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Haskell has syntactic sugar to show the arrow type in between the types as an infix function. That's how we've always used it. So let's change that:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "fmap :: (a -> b) -> (r -> a) -> (r -> b) -- (->) r a = (r -> a) \n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's the type of `fmap` for this particular instance. \n",
+ "\n",
+ "Now, we have to figure out the actual implementation. Both arguments are functions, so let's name them `f` and `g`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor ((->) r) where\n",
+ " -- fmap :: (a -> b) -> (r -> a) -> (r -> b)\n",
+ " fmap f g = ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Ok. So, as always, we need to apply the function `f` to `g` without changing the functor's structure.\n",
+ "\n",
+ "In this case, the structure is arrow `r` (`(->) r`), which means that before applying `fmap`, the function takes a value of type `r`, so, after `fmap`, the function has to still take a value of type `r`, as shown in the resulting value. So, the only thing that changes is the value returned by the function. Before `fmap` is a value of type `a`, and after is a value of type `b`.\n",
+ "\n",
+ "I'm pretty sure you could guess only by looking at the types. We need a function that takes `r` and returns `b`. And we have to obtain it using a function that takes `r` and returns `a` and a function that takes an `a` and returns a `b`. So, we compose them:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor ((->) r) where\n",
+ " -- fmap :: (a -> b) -> (r -> a) -> (r -> b)\n",
+ " fmap f g = f . g\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's it. That's the instance. We can write it more succinctly, though. If we follow this series of simple transformations:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "fmap :: (a -> b) -> (r -> a) -> (r -> b)\n",
+ "fmap f g = f . g\n",
+ "fmap f g = (.) f g -- Move `.` as prefix\n",
+ "fmap f = (.) f -- Rmv `g` from both sides\n",
+ "fmap = (.) -- Rmv `f` from both sides\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We get that the `Functor` instance for functions is actually just function composition:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor ((->) r) where\n",
+ " -- fmap :: (a -> b) -> (r -> a) -> (r -> b)\n",
+ " fmap = (.)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And now, let's try it out and test for the laws. Take into account that because we can not print functions to the console, I'll have to apply the function to some random value:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 23,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "value1 :: Int -> Int"
+ ],
+ "text/plain": [
+ "value1 :: Int -> Int"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "6"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(fmap (>4) value1) :: Int -> Bool"
+ ],
+ "text/plain": [
+ "(fmap (>4) value1) :: Int -> Bool"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "value1 :: Int -> Int\n",
+ "value1 = (*2)\n",
+ "\n",
+ ":t value1\n",
+ "value1 3\n",
+ "\n",
+ ":t (fmap (>4) value1)\n",
+ "(fmap (>4) value1) 3"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 24,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "value2 :: Bool -> Char"
+ ],
+ "text/plain": [
+ "value2 :: Bool -> Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "'1'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(fmap succ value2) :: Bool -> Char"
+ ],
+ "text/plain": [
+ "(fmap succ value2) :: Bool -> Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "'2'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "value2 :: Bool -> Char -- boolToBit function\n",
+ "value2 x = if x then '1' else '0'\n",
+ "\n",
+ ":t value2\n",
+ "value2 True\n",
+ "\n",
+ ":t (fmap succ value2)\n",
+ "(fmap succ value2) True"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 25,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "True"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "(fmap id value1) 5 == (id value1) 5\n",
+ "\n",
+ "(fmap id value2) False == (id value2) False"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "It works!! \n",
+ "\n",
+ "It's ok if you don't fully understand. This is one of the more abstract `Functor` instances you'll encounter. And, at the end of the day, if you remember that `fmap` for functions is function composition, you'll be fine.\n",
+ "\n",
+ "Ok! That was the last instance we'll create today. But there are still a few other things about using `Functors` that we have to take a look at."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## Defining `<$>` and *lifting* 🏋️ a function"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "`fmap` takes only two arguments, so we can easily use it as an infix function:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 26,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 'b') 'a' (Node (Leaf 'd') 'c' (Leaf 'e'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 'b') 'a' (Node (Leaf 'd') 'c' (Leaf 'e'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"1010\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"1010\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,4,6]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,4,6]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "fmap toLower (Node (Leaf 'B') 'A' (Node (Leaf 'D') 'C'(Leaf 'E')))\n",
+ "toLower `fmap` (Node (Leaf 'B') 'A' (Node (Leaf 'D') 'C'(Leaf 'E')))\n",
+ "\n",
+ "\n",
+ "fmap (+1) (Just 3)\n",
+ "(+1) `fmap` (Just 3)\n",
+ "\n",
+ "\n",
+ "fmap (\\x -> if x then '1' else '0') [True,False,True,False]\n",
+ "(\\x -> if x then '1' else '0') `fmap` [True,False,True,False]\n",
+ "\n",
+ "\n",
+ "fmap (*2) [1,2,3]\n",
+ "(*2) `fmap` [1,2,3]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And, it turns out, it's usually more convenient to apply `fmap` as an infix function. Luckily, the `base` library has us covered, and we have this beauty:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "(<$>) :: Functor f => (a -> b) -> f a -> f b\n",
+ "(<$>) = fmap\n",
+ "\n",
+ "infixl 1 <&>\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Notice that we have to constrain the `f` type constructor as an instance of the `Functor` type class because we're using `fmap` in the definition.\n",
+ "\n",
+ "Using this infix synonym for `fmap`, we can write the previous code like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 27,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 'b') 'a' (Node (Leaf 'd') 'c' (Leaf 'e'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Node (Leaf 'b') 'a' (Node (Leaf 'd') 'c' (Leaf 'e'))"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 4"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"1010\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"1010\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,4,6]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "[2,4,6]"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "toLower `fmap` (Node (Leaf 'B') 'A' (Node (Leaf 'D') 'C'(Leaf 'E')))\n",
+ "toLower <$> (Node (Leaf 'B') 'A' (Node (Leaf 'D') 'C'(Leaf 'E')))\n",
+ "\n",
+ "\n",
+ "(+1) `fmap` (Just 3)\n",
+ "(+1) <$> (Just 3)\n",
+ "\n",
+ "\n",
+ "(\\x -> if x then '1' else '0') `fmap` [True,False,True,False]\n",
+ "(\\x -> if x then '1' else '0') <$> [True,False,True,False]\n",
+ "\n",
+ "\n",
+ "(*2) `fmap` [1,2,3]\n",
+ "(*2) <$> [1,2,3]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And that's how you use it.\n",
+ "\n",
+ "Now, there's a reason as to why this operator has a dollar sign in the middle. This is an allusion to function application. If we look at the types:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ " ($) :: (a -> b) -> a -> b\n",
+ "(<$>) :: Functor f => (a -> b) -> f a -> f b\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We see that it looks quite familiar. Not only type-wise but conceptually as well. We know from lesson 5 that functions are right-associative, so we can surround the two types to the right, and it would be the same as not having them:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ " ($) :: (a -> b) -> ( a -> b)\n",
+ "(<$>) :: Functor f => (a -> b) -> (f a -> f b)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Looking at this, we see that the function application operator takes a function `(a -> b)` and returns the same function `(a -> b)` with no change. Which we already knew. We use this operator only because it's right-associative. Allowing us to remove the parenthesis.\n",
+ "\n",
+ "But, if we look at the fmap operator (`<$>`), we see that it takes a function `(a -> b)` and returns the same function, but that now works for the functor version of `a` and `b`. This is what we call \"lifting\" a function. We say that the fmap operator (`<$>`) lifts the function `(a -> b)` to be able to work at the `f` level.\n",
+ "\n",
+ "Just in case it didn't click, let's see two examples:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 28,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/html": [
+ "toLower :: Char -> Char"
+ ],
+ "text/plain": [
+ "toLower :: Char -> Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "'a'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(toLower <$>) :: forall (f :: * -> *). Functor f => f Char -> f Char"
+ ],
+ "text/plain": [
+ "(toLower <$>) :: forall (f :: * -> *). Functor f => f Char -> f Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "Just 'a'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "boolToBit :: Bool -> Char"
+ ],
+ "text/plain": [
+ "boolToBit :: Bool -> Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "'0'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/html": [
+ "(boolToBit <$>) :: forall (f :: * -> *). Functor f => f Bool -> f Char"
+ ],
+ "text/plain": [
+ "(boolToBit <$>) :: forall (f :: * -> *). Functor f => f Bool -> f Char"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ },
+ {
+ "data": {
+ "text/plain": [
+ "\"0\""
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ ":t toLower -- Type of original function\n",
+ "toLower 'A'\n",
+ "\n",
+ ":t (toLower <$>) -- Type of lifted function\n",
+ "toLower <$> Just 'A'\n",
+ "\n",
+ "\n",
+ "boolToBit :: Bool -> Char\n",
+ "boolToBit x = if x then '1' else '0'\n",
+ "\n",
+ ":t boolToBit -- Type of original function\n",
+ "boolToBit False\n",
+ "\n",
+ ":t (boolToBit <$>) -- Type of lifted function\n",
+ "boolToBit <$> [False]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And now that we have this new frame of looking at `fmap` and its infix synonym, we can easily understand how to deal with nested functors."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## `Functor` nesting dolls 🪆"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Nested functors are pretty common in Haskell because we combine types a lot. For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 29,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "value1 :: Either String Bool\n",
+ "value1 = Right False\n",
+ "\n",
+ "value2 :: [Either String Bool]\n",
+ "value2 = [Left \"error\", Right True, Right False]\n",
+ "\n",
+ "value3 :: Maybe [Either String Bool]\n",
+ "value3 = Just [Left \"error\", Right True, Right False]\n",
+ "\n",
+ "value4 :: Tree (Maybe [Either String Bool])\n",
+ "value4 = Leaf $ Just [Left \"error\", Right True, Right False]"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "All these values are nested functors. The number at the end of the name indicates the levels of nesting. `value4`, for example, has 4 levels of nesting: The `Either a` functor is inside the list functor, which is inside the `Mabye` functor, which is inside the `Tree` functor.\n",
+ "\n",
+ "If you notice, all `values` have booleans at their core. So, if we want to modify them, we need to map a function that takes booleans as inputs. We already have `boolToBit`, so let's use that one:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 30,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [
+ {
+ "data": {
+ "text/plain": [
+ "Right '0'"
+ ]
+ },
+ "metadata": {},
+ "output_type": "display_data"
+ }
+ ],
+ "source": [
+ "boolToBit :: Bool -> Char\n",
+ "boolToBit x = if x then '1' else '0'\n",
+ "\n",
+ "fmap boolToBit value1 -- value1 :: Either String Bool"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So far, so good. Now, if we try to do the same with `value2`: "
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": 31,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [
+ {
+ "ename": "",
+ "evalue": "",
+ "output_type": "error",
+ "traceback": [
+ "\n",
+ "
"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "Just (\\a b c -> a + b * c) <*> Just 1 <*> Just 2 <*> Just 3"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "No issue with that. It works using the apply operator we just defined. \n",
+ "\n",
+ "Another case is to have the need to apply a function that is not a functor to a bunch of functors:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- ❌ Not a Functor ❌\n",
+ "-- /-------------------\\\n",
+ "-- (\\a b c -> a + b * c) <*> Just 1 <*> Just 2 <*> Just 3 -- ❌ \n",
+ "-- __|\n",
+ "-- |\n",
+ "(\\a b c -> a + b * c) <$> Just 1 <*> Just 2 <*> Just 3 -- ✅"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "No issue either. That is what `fmap` is for. We use it to lift the function and keep going with apply operators.\n",
+ "\n",
+ "But, we could also encounter a third scenario. One when one or more values aren't functors:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "-- DB Local DB\n",
+ "Just (\\a b c -> a + b * c) <*> Just 1 <*> 2 <*> Just 3\n",
+ "-- ^\n",
+ "-- |\n",
+ "-- ❌ Not a Functor! ❌\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This happens in tons of scenarios. For example, if two of the three values come from the database and the other one is provided locally.\n",
+ "\n",
+ "We currently have no way to solve this. `fmap` lifts functions, not constant values. So, we need a way to lift arbitrary values. This function should take any value and return it embedded in a Functor. We could call this function `lift`, but for reasons we'll explain in the second to last section of this lesson, we'll call it `pure`:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "pure :: Functor f => a -> f a\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Regardless of how it's called, what it does is to lift values to the functor level. \n",
+ "\n",
+ "We can define it trivially for the `Maybe` type like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "pureMaybe :: a -> Maybe a\n",
+ "pureMaybe = Just\n",
+ "\n",
+ "pureMaybe 'a'\n",
+ "pureMaybe 4"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "And having this function, we can solve the missing case like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "Just (\\a b c -> a + b * c) <*> Just 1 <*> pureMaybe 2 <*> Just 3"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Of course, `pureMaybe` is specialized to the `Maybe` functor. So, it's the same as wrapping the value in a `Just` constructor. We want a function that works for all `Functors`, so this will also be part of our new type class. \n",
+ "\n",
+ "And with this second behavior, we can apply any function to any amount of values at the functor level. To prove it to you, let's define fmap for all the functions from zero to five arguments using these two new operators:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ " fmap0 :: a -> f a\n",
+ " fmap0 = pure\n",
+ " \n",
+ " \n",
+ " fmap1 :: (a -> b) -> f a -> f b\n",
+ " fmap1 g fa = pure g <*> fa -- same as: g <$> fa\n",
+ "\n",
+ "\n",
+ " fmap2 :: (a -> b -> c) -> f a -> f b -> f c\n",
+ " fmap2 g fa fb = pure g <*> fa <*> fb\n",
+ "\n",
+ "\n",
+ " fmap3 :: (a -> b -> c -> d) -> f a -> f b -> f c -> f d\n",
+ " fmap3 g fa fb fc = pure g <*> fa <*> fb <*> fc\n",
+ "\n",
+ "\n",
+ " fmap4 :: (a -> b -> c -> d -> e) -> f a -> f b -> f c -> f d -> f e\n",
+ " fmap4 g fa fb fc fd = pure g <*> fa <*> fb <*> fc <*> fd\n",
+ "\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "I removed the `Functor` constraint to avoid cluttering the slide, but remember that all the type-level `f`s are functors.\n",
+ "\n",
+ "For `fmap0`, we have a function that takes zero arguments. That's a constant value. So, we need to embed a constant value into a functor. Easy, we use `pure`.\n",
+ "\n",
+ "For `fmap1`, we have a function that takes one argument. We lift the function to the Functor level and then use the apply operator to apply the function to the argument. \n",
+ "\n",
+ "For `fmap2`, we have a function that takes two arguments. We lift the function to the Functor level and then use the apply operator to apply the function to both arguments.\n",
+ "\n",
+ "And it's the same for `fmap3`, 4, and 5. Lift the function and use the apply operator as many times as needed until the function is fully applied.\n",
+ "\n",
+ "And, as I'm sure you might notice, `fmap1` is the same as our regular `fmap`. And `fmap2`, 3, 4, and 5 all start with the same `pure g <*> fa` pattern. So, we can simplify a bit by replacing the first application of the apply operator with the functor operator to avoid having to lift the initial function before applying it:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ " fmap0 :: a -> f a\n",
+ " fmap0 = pure\n",
+ " \n",
+ " \n",
+ " fmap1 :: (a -> b) -> f a -> f b\n",
+ " fmap1 g fa = g <$> fa -- same as: pure g <*> fa \n",
+ "\n",
+ "\n",
+ " fmap2 :: (a -> b -> c) -> f a -> f b -> f c\n",
+ " fmap2 g fa fb = g <$> fa <*> fb\n",
+ "\n",
+ "\n",
+ " fmap3 :: (a -> b -> c -> d) -> f a -> f b -> f c -> f d\n",
+ " fmap3 g fa fb fc = g <$> fa <*> fb <*> fc\n",
+ "\n",
+ "\n",
+ " fmap4 :: (a -> b -> c -> d -> e) -> f a -> f b -> f c -> f d -> f e\n",
+ " fmap4 g fa fb fc fd = g <$> fa <*> fb <*> fc <*> fd\n",
+ "\n",
+ " ...\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Awesome!! We have proven that we only need the apply operator and pure to handle all cases. Plus, we can use fmap to make it more concise by avoiding explicitly lifting the initial function. I guess it's time to formalize our findings!!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## The `Applicative` type class"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Let's define an initial approximation of the `Applicative` type class based on what we know now:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Initial approximation:**\n",
+ "\n",
+ "\"An `Applicative` is a `Functor` with a function to lift expressions (`pure`) and an operator that works as function application at the functor level (`<*>`)\"\n",
+ "\n",
+ "```haskell\n",
+ "class Functor f => Applicative f where\n",
+ " pure :: a -> f a\n",
+ " (<*>) :: f (a -> b) -> f a -> f b\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This is not the final type class. But it already encapsulates the concept of `Applicative`, and it's enough to define a couple of instances so we can have something to work with while we figure out the laws. Because, of course, it has laws."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Let's start by defining the instance for `Identity`:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "newtype Identity a = Identity { getValue :: a } deriving (Show, Eq)\n",
+ "\n",
+ "instance Functor Identity where\n",
+ " --fmap :: (a -> b) -> Identity a -> Identity b\n",
+ " fmap f (Identity a) = Identity (f a)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Of course, because `Applicative` is a subclass of `Functor`, we first define `Functor`. It's pretty straightforward. We pattern match to extract the value wrapped with the `Identity` constructor, apply the function to the underlying value, and wrap it again. Now to the new part:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "instance Applicative Identity where\n",
+ " -- pure :: a -> Identity a\n",
+ " pure = Identity\n",
+ " \n",
+ " -- (<*>) :: Identity (a -> b) -> Identity a -> Identity b\n",
+ " -- Identity f <*> Identity a = Identity (f a)\n",
+ " Identity f <*> ia = fmap f ia -- same as definition above"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "To create an instance for the applicative type class, we need to define both `pure` and the apply operator. We don't have much choice for `pure`. We need to lift a value to the `Identity` level, and we have only one constructor with the same type as pure. So we use that.\n",
+ "\n",
+ "For the apply operator, we have two choices. We can pattern-match to extract both the function and the value, apply the function to the value, and wrap it again, or because we have `fmap` at our disposal, we can pattern-match to extract only the function and fmappit to the value. If you look at the definition of the functor instance, it's the same, but we avoid repeating ourselves.\n",
+ "\n",
+ "Now that the `Identity` type is an applicative functor, we can use the operators:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "Identity (+1) <*> Identity 1\n",
+ "\n",
+ "Identity (+) <*> Identity 1 <*> Identity 2\n",
+ "\n",
+ "Identity (\\a b c -> a + b * c) <*> Identity 1 <*> pure 2 <*> pure 3"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "That one was boring, so let's do a new one. Let's create an instance for the `Maybe` type. Same as before, we start with the functor instance:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "data Maybe a = Nothing | Just a\n",
+ "\n",
+ "-------------------------------------------------------------------------\n",
+ "\n",
+ "instance Functor Maybe where\n",
+ " -- fmap :: (a -> b) -> Maybe a -> Maybe b\n",
+ " fmap _ Nothing = Nothing\n",
+ " fmap f (Just x) = Just (f x)\n",
+ "\n",
+ "-------------------------------------------------------------------------\n",
+ "\n",
+ "instance Applicative Maybe where\n",
+ " -- pure :: a -> Maybe a\n",
+ " -- pure = \\x -> Nothing ❌\n",
+ " pure = Just\n",
+ " \n",
+ " -- (<*>) :: Maybe (a -> b) -> Maybe a -> Maybe b\n",
+ " Just f <*> ma = fmap f ma\n",
+ " _ <*> _ = Nothing\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We don't run this cell because these instances are already provided by the prelude.\n",
+ "\n",
+ "We already implemented the `Functor` instance in the previous lesson, so we won't go there.\n",
+ "\n",
+ "For the `Applicative` instance, we have two options that satisfy the types for `pure`. We could create a function that ignores the input and returns `Nothing`, or we could use `Just` that fits perfectly fine by itself. Conceptually, it makes sense to use `Just` because if we use `Nothing`, we'll always get `Nothing` independent of the value we lift. But, if that doesn't convince you, `Just` is the only option if we want to respect the laws of the type class!"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## The `Applicative` laws"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Remember that one of the characteristics of functors was that `fmap` didn't change the structure itself. Only the values. Here, the apply operator has the same restriction.\n",
+ "\n",
+ "Sadly, same as with `Semigroup`, `Monoid`, and `Functor`, not everything is reflected in the type class definition. So, we have to complement it with a few laws. Here they are:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Identity:**\n",
+ "```haskell\n",
+ "pure id <*> v = v\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Applying a lifted `id` function to an applicative should return the same applicative. This makes sense, right? Same as when we deal with `fmap`, the apply operator should respect the structure of the `Functor` that is now an `Applicative` functor. Let's see an example with the `Maybe` type:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "(pure id <*> Just 3) == Just 3\n",
+ "\n",
+ "--------------------------------------------\n",
+ "\n",
+ "wrongPure = \\x -> Nothing\n",
+ "\n",
+ "(wrongPure id <*> Just 3) == Just 3"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, the apply operator should also respect the structure of the functor and only modify the values. If we don't do anything to the values, we should get our original applicative functor. That's why we have to use `Just` as `pure`. If we use a function like `wrongPure` that ignores the input and always returns `Nothing`, we have the correct type, but we change the structure when applying a lifted id function.\n",
+ "\n",
+ "Next, we have the Homomorphism law:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Homomorphism:**\n",
+ "```haskell\n",
+ "pure f <*> pure x = pure (f x)\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Applying a lifted function to a lifted value should be the same as applying the function to the value and then lifting the result. This enforces that the apply operator has to behave as the regular function application.\n",
+ "\n",
+ "Let's see an example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "leftSide :: Maybe String\n",
+ "leftSide = pure show <*> pure 3\n",
+ "\n",
+ "rightSide :: Maybe String\n",
+ "rightSide = pure (show 3)\n",
+ "\n",
+ "leftSide == rightSide\n",
+ "leftSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Amazing! It works as expected!! We still have two more to go through, though. Next, we have the composition law:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Composition:**\n",
+ "```haskell\n",
+ "(pure (.) <*> u <*> v) <*> w = u <*> (v <*> w) \n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This one shows that the operator is associative, although it might not be evident at a glance, so here's an example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "leftSide = (pure (.) <*> Just show <*> Just (*2)) <*> Just 3\n",
+ "rightSide = Just show <*> (Just (*2) <*> Just 3)\n",
+ "\n",
+ "\n",
+ "leftSide == rightSide\n",
+ "leftSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "On the left side, we want to combine the `show` function with the `(*2)` function first and then apply it to `3`. And we know that the way of combining functions is by composition. So, we lift function composition to the functor level and apply it to `Just show` and `Just (*2)`. Then, we apply the result of that composition to `Just 3`.\n",
+ "\n",
+ "On the right side, we first want to combine the last two and then combine the result with the first. In this case, we don't need to lift function composition because we can apply `Just (*2)` to `Just 3` directly. So we do that to get `Just 6` and then apply `Just show` to get the string representation of the number six.\n",
+ "\n",
+ "As you can see, we get the same result on both sides.\n",
+ "\n",
+ "Finally, we have the interchange law:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Interchange:**\n",
+ "```haskell\n",
+ "f <*> pure x = pure (\\f -> f x) <*> f\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This one states that we should get the same result if we flip the arguments when applying a function. We know this is true for regular function applications. For example:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "leftSide = (+1) 3\n",
+ "rightSide = (\\f -> f 3) (+1) \n",
+ "\n",
+ "\n",
+ "leftSide == rightSide\n",
+ "leftSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "notes"
+ }
+ },
+ "source": [
+ "On the left side, we apply the function `(+1)` and to 3 to get 4.\n",
+ "\n",
+ "On the right side, we apply a function that takes another function as a parameter and applies it to the number three to the `(+1)` function. This results in `+1` being passed as a parameter and being applied to `3`.\n",
+ "\n",
+ "As you can see, we have to do the extra step of adding a lambda function, but if we flip the arguments of function application, we still get the same result. That property should also hold with our apply operator:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": false,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "leftSide = Just (+1) <*> pure 3\n",
+ "rightSide = pure (\\f -> f 3) <*> Just (+1) \n",
+ "\n",
+ "\n",
+ "leftSide == rightSide\n",
+ "leftSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "This is the same as we just saw but lifted at the applicative functor level.\n",
+ "\n",
+ "Same as before, we have to do the extra step of adding a lambda function. But if we flip the arguments of the apply operator, we still get the same result. And that's it! \n",
+ "\n",
+ "To hone in on the type class implementation, let's do one more before moving on. Let's create the `Applicative` instance for the `Either` type:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "```haskell\n",
+ "instance Functor (Either e) where\n",
+ " fmap f (Left e) = Left e\n",
+ " fmap f (Right a) = Right (f a)\n",
+ "\n",
+ "-----------------------------------------------------------\n",
+ "\n",
+ "instance Applicative (Either e) where\n",
+ " -- pure :: a -> Either a a\n",
+ " pure = Right\n",
+ " -- (<*>) :: Either e (a -> b) -> Either e a -> Either e b\n",
+ " Left e <*> _ = Left e\n",
+ " Right f <*> r = fmap f r\n",
+ "```"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We use `Right` to lift the value with `pure`. If we follow the types, `Right` is our only choice. Also, it makes sense. Lifting anything to the `Left` constructor would be useless because it would make any function that uses it return `Left` regardless of the other values it's applied to. On top of that, it also makes sense from the `Functor` perspective. `Left e` is part of the structure. We want to lift a value, so we have to use a constructor that can hold a value, and the only one available is the `Right` constructor that can hold values of type `a`.\n",
+ "\n",
+ "And for the apply operator, we have to take into account the cases that the function is both a `Left` and `Right`. If the function is a `Left`, it means we don't have a function. We have an error. So, we have no other option than propagating the error.\n",
+ "\n",
+ "If the constructor is a `Right`, we do have the function. And in this case, we could have both `Left` and `Right` as the second argument, but we don't have to deal with that because we already defined `fmap` that does it for us. So, we just `fmap` the funciton.\n",
+ "\n",
+ "And that's it! If we try to use it, we see that the results are reasonable:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "scrolled": true,
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "Right (+1) <*> pure 1\n",
+ "\n",
+ "(+) <$> Right 1 <*> Right 2\n",
+ "\n",
+ "(\\a b c -> a + b * c) <$> pure 1 <*> Left 2 <*> pure 3\n",
+ "\n",
+ "(\\a b c -> a + b * c) <$> Right 1 <*> pure 2 <*> pure 3"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "But reasonable is not enough. We have to check if our instance follows the Applicative laws. So, let's do that. Starting with the identity law:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- Identity: pure id <*> v = v\n",
+ "\n",
+ "\n",
+ "(pure id <*> Left 3) == Left 3\n",
+ "\n",
+ "(pure id <*> Right 'a') == Right (id 'a')"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Nice. Our implementation follows the identity law. Now let's check for the Homomorphism law:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- Homomorphism: pure f <*> pure x = pure (f x)\n",
+ "\n",
+ "\n",
+ "leftSide :: Either e Int\n",
+ "leftSide = pure (+1) <*> pure 1\n",
+ "\n",
+ "rightSide :: Either e Int\n",
+ "rightSide = pure ((+1) 1)\n",
+ "\n",
+ "\n",
+ "leftSide == rightSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Awesome! 2/4 done. Let's do composition next:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- Composition: pure (.) <*> u <*> v <*> w = u <*> (v <*> w)\n",
+ "\n",
+ "\n",
+ "leftSide :: Either String Int\n",
+ "leftSide = pure (.) <*> u <*> v <*> w\n",
+ " where\n",
+ " u = Right (+1)\n",
+ " -- v = Right (*2)\n",
+ " v = Left \"some error\"\n",
+ " w = Right 3\n",
+ "\n",
+ "rightSide :: Either String Int\n",
+ "rightSide = u <*> (v <*> w)\n",
+ " where\n",
+ " u = Right (+1)\n",
+ " -- v = Right (*2)\n",
+ " v = Left \"some error\"\n",
+ " w = Right 3\n",
+ "\n",
+ "\n",
+ "leftSide == rightSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "As you can see, this law holds as well. And, of course, we can change any of these three values to different ones, for example, `Left \"some error\"`, and it will still hold.\n",
+ "\n",
+ "And finally, we check for the interchange law:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- Interchange: u <*> pure y = pure ($ y) <*> u\n",
+ "\n",
+ "\n",
+ "leftSide :: Either String Int\n",
+ "leftSide = u <*> pure 5\n",
+ " where\n",
+ " u = Right (+1)\n",
+ " -- u = Left \"some error\"\n",
+ "\n",
+ "rightSide :: Either String Int\n",
+ "rightSide = pure ($ 5) <*> u\n",
+ " where\n",
+ " u = Right (+1)\n",
+ " -- u = Left \"some error\"\n",
+ "\n",
+ "\n",
+ "leftSide == rightSide"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Amazing! Our implementation seems to follow all the `Applicative` laws. We now have the Identity, Maybe, and Either Applicatives under our belt. So, I think it's time to move on to programming with effects."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "## 🎆 Programming with effects 🎆"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Congratulations! You now know how to program with effects!! Oh, you didn't realize that? Well, you do! Here's why.\n",
+ "\n",
+ "When we talked about `Maybe`, we said it gave us a way to represent values that might fail. We wanted to return a value, but we weren't sure if we were going to be able to, so we used `Mabye`:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "-- We used optional values to create safe versions of partial functions\n",
+ "safeDiv :: Int -> Int -> Maybe Int\n",
+ "safeDiv x 0 = Nothing\n",
+ "safeDiv x y = Just (x `div` y)\n",
+ "\n",
+ "8 `safeDiv` 2\n",
+ "8 `safeDiv` 0\n",
+ "\n",
+ "-------------------------------------------------------------------------------\n",
+ "\n",
+ "-- We used optional values to handle possible failed results\n",
+ ":t lookup\n",
+ "valueFromDB = lookup \"Eren\" [(\"Eren\", 10), (\"Mikasa\", 25), (\"Armin\", 7)] -- Fake Database call\n",
+ "valueFromDB"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "In the first example, we see how we use optional values to create a safe version of `div` that doesn't crash our program if we try to divide by zero.\n",
+ "\n",
+ "In the second example, we represent a value we retrieve from a database. The value could have not been there, so the `lookup` function produces a value of type `Maybe` to be able to return `Nothing` if it can't find the value in the list.\n",
+ "\n",
+ "Now, imagine we need to apply the `calculate` function to a bunch of `Maybe` values:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "calculate :: Int -> Int -> Int -> Int\n",
+ "calculate a b c = a + b * c"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Before learning about `Functor` and `Applicative`, we could have defined a function that takes three `Maybe` values and applies `calculate` to them like this:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "calculateMaybe ma mb mc = case ma of\n",
+ " Nothing -> Nothing\n",
+ " Just a -> case mb of\n",
+ " Nothing -> Nothing\n",
+ " Just b -> case mc of\n",
+ " Nothing -> Nothing\n",
+ " Just c -> Just (calculate a b c)\n",
+ "\n",
+ "\n",
+ "calculateMaybe (8 `safeDiv` 2) (pure 2) valueFromDB"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We create a new `calculateMaybe` function to manually handle all possible failure cases. If all three values return a `Just`, we know we have all three underlying numbers, and we can apply the original `calculate` function to them. And, of course, we wrap the result in a `Just` constructor to get the correct type.\n",
+ "\n",
+ "This has several disadvantages. One is that we have to create the new `calculateMaybe` function. Another is that `calculateMaybe` only works for `Maybe` values. Finally, we have to write a massive block pattern matching with case expressions to handle the `Maybe` values three times. The same code is repeated thrice."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "But now that we have `Functor` and `Applicative`, we can do the same in one line:"
+ ]
+ },
+ {
+ "cell_type": "code",
+ "execution_count": null,
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "outputs": [],
+ "source": [
+ "calculate <$> (8 `safeDiv` 2) <*> (pure 2) <*> valueFromDB"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We don't have to create a new function, we can replace the values we apply `calculate` to with any type that is an instance of applicative, and we don't have to handle the failure cases by hand because that is handled by the operators under the hood. This is what we achieved code-wise. But there's a different way of looking at this."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "We can also think of `Maybe` as a type that provides the simulated effect of exception handling. In that case, the apply operator is a way to sequence effects and combine their results. As you can see in `calculateMaybe`, we sequence the exception handling one after the other and then apply `calculate` at the end to combine their results.\n",
+ "\n",
+ "When we apply functions using the applicative operators, also called \"applicative style\", we do the same as in `calculateMaybe` but in a hidden and more convenient way. That's why it's understandable to be confused when I tell you we can think of it as an effect when you can clearly see in the body of `calculateMaybe` that it's actually pure code.\n",
+ "\n",
+ "In Haskell, we have a bit of a loose concept of effects. Sometimes, the same code can be thought of as having an effect or not, depending on how you interpret it. So, to make it as crystal clear as possible, here are a few key clarifications that will save you a lot of time and headaches:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "Haskell has both **real effects** and **simulated effects**.\n",
+ "- **Real** effects are impure and unpredictable (e.g., `IO`)\n",
+ "- **Simulated** effects look impure when you use them, but are actually pure under the hood (e.g., `Maybe`)"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "Simulated effects look impure because the computations are hidden from us behind types and operators. So, from the point of view of the user of those types and operators, it looks like they are running side effects, but it's actually pure code that they can not see.\n",
+ "\n",
+ "Another worthy clarification is that:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "fragment"
+ }
+ },
+ "source": [
+ "Independently of whether they are real or simulated, **all effects** have an **associated type** and **at least an `Applicative` instance** (usually a `Monad` instance as well)."
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "skip"
+ }
+ },
+ "source": [
+ "So, `Applicative` and `Monad` are the interfaces for effects. You can think of these type classes as the boundary between what it is and is not usually considered an effect. As a side note, don't worry about `Monad` yet. We'll cover it in a future lesson. Just know that `Monads` have a close relationship with `Applicative` and the concept of effects.\n",
+ "\n",
+ "Let's see a few examples:"
+ ]
+ },
+ {
+ "cell_type": "markdown",
+ "metadata": {
+ "slideshow": {
+ "slide_type": "slide"
+ }
+ },
+ "source": [
+ "**Examples of effects in Haskell:**\n",
+ "\n",
+ "- `Identity` provides **no effect**.\n",
+ "If you ran all cells until now, restart the Kernel before continuing. This is to prevent errors due to the class of multiple <*> definitions.
\n", + "\n", + "- `Maybe` provides the **simulated effect** of a computation that might fail.\n", + "
\n", + "\n", + "- `Either` provides the **simulated effect** of a computation that might fail with an error message or some context as to why we had an error.\n", + "
\n", + "\n", + "- `[]` provides the **simulated effect** of a non-deterministic computation. A computation that can have zero, one, or multiple results (each element on the list is a result).\n", + "
\n", + "\n", + "- `IO` provides the **real effect** of interacting with the world (keyboard, screen, internet,...)." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We'll discuss more effects in later lectures, but let's stick with these ones for now to avoid overwhelming ourselves.\n", + "\n", + "And thinking on these terms, now it makes sense why we called `pure` the function we use to lift values to the applicative functor level.\n", + "\n", + "It's because we're embedding a value without an effect, a pure value, into an effectful context. \n", + "\n", + "Once again, all we do with `pure` is to wrap the value with the correct expression, the same as we have been doing during this lesson. That hasn't changed. It's the way we think about what we do that changed." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We'll talk more about effects when we cover `Monads`. For now, with this new point of view, let's finish this lesson the same way we did with the `Functor` one. By exploring the extra functions we get for free with `Applicative` and presenting the type class and how it's defined in the `base` library." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## Extra functions and `Applicative` as defined in `base`" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The first functions we'll take a look at are the lift functions:" + ] + }, + { + "cell_type": "code", + "execution_count": 29, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "[2,3]" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Just 4" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "[4,5,5,6]" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Right 5" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Left \"some error\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Just 14" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "liftA :: Applicative f => (a -> b) -> f a -> f b\n", + "liftA f x = pure f <*> x -- Lift a unary function to actions.\n", + "\n", + "liftA2 :: Applicative f => (a -> b -> c) -> f a -> f b -> f c\n", + "liftA2 f x y = f <$> x <*> y -- Lift a binary function to actions.\n", + "\n", + "liftA3 :: Applicative f => (a -> b -> c -> d) -> f a -> f b -> f c -> f d\n", + "liftA3 f x y z = liftA2 f x y <*> z -- Lift a ternary function to actions.\n", + "\n", + "--------------------------------------------------------------------------------\n", + "\n", + "liftA (+1) [1, 2]\n", + "liftA (+1) (Just 3)\n", + "\n", + "liftA2 (+) [1, 2] [3, 4]\n", + "liftA2 (+) (Right 2) (Right 3)\n", + "\n", + "liftA3 (\\a b c -> a + b * c) (Right 2) (Left \"some error\") (Right 4)\n", + "liftA3 (\\a b c -> a + b * c) (Just 2) (Just 3) (Just 4)" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "These three functions are the same as we defined earlier as `fmap`, `fmap2`, and `fmap3`. They take functions that take one, two, and three arguments and lift them to work at the applicative functor level. Their names start with `lift` because we're lifting functions. Then, they continue with a capital `A` because we're lifting them to the applicative level and end with the number of arguments the lifted function takes. You'll encounter functions with this naming convention regularly since it's used all over the `base` library. So it's good to get used to it.\n", + "\n", + "It seems like a bad joke. I just told you we don't need to define functions like these ones. And we don't! As you can see in the definitions, we can write any of them using only applicative style.\n", + "\n", + "But there are reasons as to why we have these ones. Well, there are historical reasons. So, maybe if we wanted to design Haskell from scratch with what we know right now, we wouldn't have these functions. But there are also subtle non-historical reasons as to why we have them.\n", + "\n", + "On one hand, because `liftA` and `fmap` are the same function, you could implement first the `Applicative` instance of a type and then implement the `Functor` instance defining `fmap` as a synonym to `liftA`. It seems counterintuitive because `Functor` is a superclass of `Applicative`. But, the same as we have mutually recursive functions for the Eq type class, the compiler doesn't care as long as both instances are defined and we eventually reach a base case. So, if, for some reason, defining the pure and apply operators is easier than defining `fmap`, you have the option of doing this. That's also why we use `pure` and the apply operator instead of `fmap` to define `liftA`. If we did that, and then you define `fmap` using `liftA`, we'll get infinite recursion. If that didn't make sense, it's OK. It's an implementation detail, not crucial.\n", + "\n", + "Moving on to `liftA2`, it turns out that some functors support an implementation of `liftA2` that is more efficient than using `fmap` and the apply operator. In particular, if `fmap` is an expensive operation, you can redefine the standard definition of `liftA2` shown here with a more optimized one. That way, it would be better to use the optimized `liftA2` than to `fmap` over the structure and then use `<*>`. We don't care about optimizing our code for now, so, for us, it's just a shorter way of lifting a binary function.\n", + "\n", + "And finally, `liftA3` is there because counting to two feels incomplete.\n", + "\n", + "Jokes aside, in most scenarios, you should use `fmap` instead of `liftA`. And, if you have to lift a binary or ternary function, feel free to use `liftA2` and `liftA3` or applicative style. Whatever you like the best." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Now, let's move to more interesting ones.\n", + "\n", + "Analogous to the `Functor` case, we have these two operators:" + ] + }, + { + "cell_type": "code", + "execution_count": 30, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Just 3" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Nothing" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "-- Sequence actions, discarding the value of the first argument.\n", + "(*>) :: Applicative f => f a -> f b -> f b\n", + "a1 *> a2 = (id <$ a1) <*> a2 \n", + "\n", + "\n", + "Just 2 *> Just 3\n", + "Nothing *> Just 3" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The one that discards the value of the first argument, and:" + ] + }, + { + "cell_type": "code", + "execution_count": 31, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "Just 2" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "Nothing" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "-- Sequence actions, discarding the value of the second argument.\n", + "(<*) :: Applicative f => f a -> f b -> f a\n", + "(<*) = liftA2 const \n", + "\n", + "\n", + "Just 2 <* Just 3\n", + "Nothing <* Just 3" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The one that discards the value of the second argument." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We said that the apply operator sequences effects/computations/actions and combines their result. Well, these ones do the same but discard the value produced by one of the inputs. Notice that, same as with their analogous of the `Functor` type class, the arrow points to the value you'll get.\n", + "\n", + "If you want to perform the effect or computation but don't care about the result, like printing to the console, you can use one of these." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Then, we have the reversed application operator:" + ] + }, + { + "cell_type": "code", + "execution_count": 32, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "\"Retrieve value from DB\"\n", + "\"Save value in DB\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "\"Retrieve value from DB\"\n", + "\"Save value in DB\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "\"Save value in DB\"\n", + "\"Retrieve value from DB\"" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "(<**>) :: Applicative f => f a -> f (a -> b) -> f b\n", + "(<**>) = liftA2 (\\a f -> f a) -- A variant of '<*>' with the types of the arguments reversed.\n", + "\n", + "-----------------------------------------------------------------------------------------------\n", + "\n", + "-- Attempt 1: Correct values, wrong effect order\n", + "(<*>) (id <$ print \"Retrieve value from DB\") (print \"Save value in DB\") \n", + "\n", + "-- Attempt 2: Corect values, wrong effect order\n", + "(flip (<*>)) (print \"Save value in DB\") (id <$ print \"Retrieve value from DB\")\n", + "\n", + "-- Attempt 3: Correct values, correct effect order\n", + "(<**>) (print \"Save value in DB\") (id <$ print \"Retrieve value from DB\")" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "This operator does the same as the apply operator, but it first takes the applicative value and then the applicative function.\n", + "\n", + "This operator is helpful in cases where the values you get are ok, but the effects are in the wrong order. In this example, we're using `IO` effects. The `IO` type is an instance of `Applicative`. \n", + "\n", + "In the first attempt, we evaluate the first Applicative and retrieve the value from our database. Then, we evaluate the second Applicative and save the value to the database. After running both effects, we apply the `id` function to the result of print, which is a unit.\n", + "\n", + "The problem is, the effects are in the wrong order! We first need to save the value so we can then retrieve it. But we can not just change the order of the arguments. The result of the first effect is a function (in this case, the `id` function), and the result of the second effect is the constant value unit. One is a function, and the other is a constant value. So, what do we do?\n", + "\n", + "One solution you could think of is to use the `flip` function we learned many lessons ago. It's designed to specifically flip the arguments of the function. That's what we see in the second attempt. And the code looks fine. But, if we evaluate the expression, we reduce this expression, and we end up having the same final one. The `flip` function only changes how we provide values to the original function but not how the values are evaluated. So, even if we write the values in a different order, the effects run in the same order. This is the problem this new operator solves. It not only flips the arguments but also resolves the effects in the order they are presented. So, we can finally first save the value in the database and then retrieve it." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Another useful one is the `forever` function:" + ] + }, + { + "cell_type": "code", + "execution_count": null, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "name": "stdout", + "output_type": "stream", + "text": [ + "firsr\n", + "second\n", + "third\n", + "fourth\n", + "...\n" + ] + } + ], + "source": [ + "forever :: (Applicative f) => f a -> f b\n", + "forever a = a *> forever a -- Same as: a *> a *> a *> a... infinitely\n", + "\n", + "\n", + "forever getLine" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "As you can see by the definition, we get an applicative, perform its effect, ignore the result, and recursively run `forever` with the same Applicative. This function will never stop by itself.\n", + "\n", + "It's the first time we have a forever looping function that is actually useful! Now that we have Applicatives, we can perform effects. So, now, infinite loops make sense because we're not interested in what the function returns but in what the effect does. A common use case, for example, is to have a server forever listening to client connections. As we saw before, the `IO` type is an instance of Applicative, so we can use the `*>` sequence operator. You want the server to keep listening as long as you have it running, so you use an infinite loop.\n", + "\n", + "Another cool thing we can do with `Applicative` is to have conditional execution of expressions:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "-- Execute Applicative if Bool is True:\n", + "when :: (Applicative f) => Bool -> f () -> f ()\n", + "when = 😳\n", + "\n", + "-- Execute Applicative if Bool is False:\n", + "unless :: (Applicative f) => Bool -> f () -> f ()\n", + "unless = 🫣\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Here, we have the `when` and `unless` functions. `when` executes the applicative expression only when Bool is true. And `unless` executes it unless it's true. I'm not showing you the implementation because you'll have to implement them yourself on the homework. But an example will do fine:" + ] + }, + { + "cell_type": "code", + "execution_count": 2, + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "when is True" + ] + }, + "metadata": {}, + "output_type": "display_data" + }, + { + "data": { + "text/plain": [ + "unless is False" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "import Control.Monad (when, unless)\n", + "\n", + "\n", + "when True (putStrLn \"when is True\")\n", + "when False (putStrLn \"when is False\")\n", + "-----------------------------------------\n", + "unless True (putStrLn \"unless is True\")\n", + "unless False (putStrLn \"unless is False\")" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "You might have noticed that I'm importing the functions from `Control.Monad` instead of `Control.Applicative`. That's because these functions (and others we'll discuss later) were constrained by the Monad type class before the Applicative type class was fully integrated into the base library. Because maintainers wanted to minimize breaking changes, these (and other) functions were left in the Monad module but with the Applicative constraint instead of the Monad constraint. So, for all intents and purposes, these are Applicative functions that happen to be in a different module because of historical reasons.\n", + "\n", + "If you think we're talking a lot about Monads for a lesson about Applicatives, it's because before, this behavior of sequencing effects was found in the Monad type class. So, the Applicative type class stole a lot of the work that used to be done by the Monad type class, and there are still a few loose ends sprinkled around the `base` library.\n", + "\n", + "Coming back to the `when` and `unless` functions, to give you some extra help, take a look at this example:" + ] + }, + { + "cell_type": "code", + "execution_count": 3, + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "14\n", + "12\n", + "10\n", + "8\n", + "6\n", + "4\n", + "2\n", + "0" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "printEvenNumbersUntilZero :: Int -> IO ()\n", + "printEvenNumbersUntilZero n = when (even n) (print n) *> \n", + " unless (n <= 0) (printEvenNumbersUntilZero (n-1))\n", + "\n", + "printEvenNumbersUntilZero 15" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "You can almost read the expression as if it were plain English. The `printEvenNumbersUntilZero` function takes a number, and when it's even, it prints it. Then, unless it's less or equal to zero, it recursively calls `printEvenNumbersUntilZero` with the number reduced by one.\n", + "\n", + "This is just one example of things you could do with these functions.\n", + "\n", + "I think those were enough clues for you. Let's keep going, two functions to go:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "replicateM :: (Applicative m) => Int -> m a -> m [a]\n", + "replicateM n action | n <= 0 = pure []\n", + " | otherwise = (:) <$> action <*> replicateM (n-1) action\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The `replicateM` function takes an `Int` that we named `n` and an applicative that we named `action`. Then, it executes the action n times and returns an Applicative with a list containing all the results.\n", + "\n", + "Same as with the `when` and `unless` functions, `replicateM` suffers from historical baggage. It has an upper-case `M` at the end, signaling that it works with Moads, and the type variable constrained by `Applicative` is a lower-case `m`, signaling that it used to be a type variable constrained by Monads. If we would write the `base` library from scratch today, we would likely call this function `replicateA` and use `f` for the type variable. But do not let that distract you. For you, this is an Applicative function, the same as the others.\n", + "\n", + "In the definition, we have two cases. If the number is zero or negative, we shouldn't do anything, so we return an empty list lifted to the Applicative level. Or, in other words, we embed a pure empty list in the effect of the Applicative. Whichever might be.\n", + "\n", + "Otherwise, we have a number larger than zero, so we run the action and add the result to a list. We can do that easily thanks to the fmap and apply operators. And since we have to accumulate the results in a list, we concatenate them. So, we use fmap to apply the pure cons operator to our applicative, and then we apply the partially applied cons operator at the applicative level to a recursive call of `replicateM` with a reduced `n`. So, we will keep lifting cons operators and applying them to the result of evaluating the applicative until we reach zero and return the empty list. At that point, we have a list of all the results concatenated in a list, which is what we needed.\n", + "\n", + "Let's see an example:" + ] + }, + { + "cell_type": "code", + "execution_count": 4, + "metadata": { + "scrolled": true, + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "What are your 3 favorite Pokemon?\n", + "[\"Pikachu\",\"Mimikyu\",\"Scizor\"]" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "import Control.Monad (replicateM)\n", + "\n", + "get3Answers :: String -> IO [String]\n", + "get3Answers q = putStrLn q *> replicateM 3 getLine\n", + "\n", + "get3Answers \"What are your 3 favorite Pokemon?\"" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We create the `get3Answers` function that takes a `String`, which is the question we want to ask, and returns a list of Strings containing the answers. We can use the `*>` sequence operator to first print the question, ignore the result, and then use `replicateM` to run `getLine` three times and get the result as a list of strings." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We also have a variation of `replicateM` called `repliacteM_`:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "replicateM_ :: (Applicative m) => Int -> m a -> m ()\n", + "replicateM_ = 🤷\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "The underscore at the end is another naming convention followed by many functions that deal with effects. If a function ends with an underscore, it means that it ignores the result and returns the `()`. So, if you only care about the effect and not the value, use a function that ends with an underscore. \n", + "\n", + "It's usual to have the same function with and without the underscore. Both do the same, but one returns a value, and the other returns a useless `()`.\n", + "\n", + "So, now that you know this, you know what `replicateM_` does. It does the same as `replicateM` but returns `()` instead of the list of resulting values. I'm not going to show the implementation because you have to do it in the homework, but here is an example of why would you want to use it:" + ] + }, + { + "cell_type": "code", + "execution_count": 5, + "metadata": { + "slideshow": { + "slide_type": "fragment" + } + }, + "outputs": [ + { + "data": { + "text/plain": [ + "What are your 3 favourite pokemon?" + ] + }, + "metadata": {}, + "output_type": "display_data" + } + ], + "source": [ + "import Control.Monad (replicateM_)\n", + "\n", + "saveToDB = id -- use your imagination\n", + "\n", + "getAndSave3Answers :: String -> IO ()\n", + "getAndSave3Answers q = putStrLn q *> replicateM_ 3 (saveToDB getLine)\n", + "\n", + "getAndSave3Answers \"What are your 3 favourite pokemon?\"" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Here, we create the `getAndSave3Answers` function that does the same as the `get3Answers` function, but now it saves the answers in a database.\n", + "\n", + "In this case, we print the question, ignore the result and then use `replicateM_` to execute the `saveToDB getLine` applicative three times. Because the applicative's effect already saves the values to the database, I have no reason to return them, so I use the underscore version of `replicateM`." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "And there are many more functions like these ones that we could talk about. But we're going to leave it here for the sake of time, and because after all we discussed so far, you can search for them in the documentation by yourself and quickly understand what they do." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "So, after all this work, this is what we've got. It's a lot, so I had to split it into 3 different slides:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "**An `Applicative` is a `Functor` with operations to embed pure expressions (`pure`) and sequence computations/effects combining their results (`<*>`).**\n", + "\n", + "```haskell\n", + "class Functor f => Applicative f where\n", + " pure :: a -> f a -- Lift a value.\n", + "\n", + " (<*>) :: f (a -> b) -> f a -> f b\n", + " (<*>) = liftA2 id -- Sequential application.\n", + "\n", + " liftA2 :: (a -> b -> c) -> f a -> f b -> f c\n", + " liftA2 f x = (<*>) (fmap f x) -- Lift a binary function to actions.\n", + "\n", + " (*>) :: f a -> f b -> f b\n", + " a1 *> a2 = (id <$ a1) <*> a2 -- <*> discarding the val of the 1st arg.\n", + " \n", + " (<*) :: f a -> f b -> f a\n", + " (<*) = liftA2 const -- <*> discarding the val of the 2nd arg.\n", + " {-# MINIMAL pure, ((<*>) | liftA2) #-}\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "If we look at how `Applicative` is defined in the `base` library, we'll see that several of the functions we just talked about are part of the type class, and three that we don't see here are not. As with `Functors`, we don't care about that distinction since they all come for free when you define the `Applicative` instance.\n", + "\n", + "As you can see, we have mutual recursion between the apply operator and `liftA2`. The rest of the functions (except for `pure`) are defined using one of those. So, at the end of the day, we have to provide `pure` with either the apply operator or `liftA2`, whichever you prefer to implement.\n", + "\n", + "On top of that, every type that has an instance of this `Applicative` type class has to respect these laws:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "### Applicative laws\n", + "
\n", + "\n", + "**Identity:**\n", + "```haskell\n", + "pure id <*> v = v\n", + "```\n", + "**Homomorphism:**\n", + "```haskell\n", + "pure f <*> pure x = pure (f x)\n", + "```\n", + "**Composition:**\n", + "```haskell\n", + "(pure (.) <*> u <*> v) <*> w = u <*> (v <*> w) \n", + "```\n", + "**Interchange:**\n", + "```haskell\n", + "f <*> pure x = pure (\\f -> f x) <*> f\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "Finally, we also gain a ton of utility functions that are not part of the type class but are available in the `base` library:" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "```haskell\n", + "(<**>) :: Applicative f => f a -> f (a -> b) -> f b\n", + "\n", + "liftA :: Applicative f => (a -> b) -> f a -> f b\n", + "\n", + "liftA3 :: Applicative f => (a -> b -> c -> d) -> f a -> f b -> f c -> f d\n", + "\n", + "forever :: Applicative f => f a -> f b\n", + "\n", + "when :: Applicative f => Bool -> f () -> f ()\n", + "\n", + "unless :: Applicative f => Bool -> f () -> f ()\n", + "\n", + "replicateM :: Applicative m => Int -> m a -> m [a]\n", + " \n", + "replicateM_ :: Applicative m => Int -> m a -> m ()\n", + "\n", + "filterM :: Applicative m => (a -> m Bool) -> [a] -> m [a]\n", + "\n", + "-- 🔥 AND MORE!!!!! 🤯\n", + "```" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "It's dramatic the number of functions we unlock by creating an instance of Applicative. So many that we couldn't cover all of them. The power that this abstraction provides is huge! Use it responsibly." + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "slide" + } + }, + "source": [ + "## And that's it for today! 😃" + ] + }, + { + "cell_type": "markdown", + "metadata": { + "slideshow": { + "slide_type": "skip" + } + }, + "source": [ + "We introduced only one more abstraction today, but we also talked about how we can interpret types that are instances of `Applicative` as effects. If that didn't quite click, it's OK. We'll talk more about effects in the monad lesson. For now, the best would be to get comfortable both defining and using the operators independently of how you think about it. And for that, make sure to do your homework, and I'll see you in the next one!!" + ] + } + ], + "metadata": { + "celltoolbar": "Slideshow", + "kernelspec": { + "display_name": "Haskell", + "language": "haskell", + "name": "haskell" + }, + "language_info": { + "codemirror_mode": "ihaskell", + "file_extension": ".hs", + "mimetype": "text/x-haskell", + "name": "haskell", + "pygments_lexer": "Haskell", + "version": "8.10.7" + } + }, + "nbformat": 4, + "nbformat_minor": 4 +} \ No newline at end of file