CS 330: Lecture 29 – Haskell IO
Up till this point we haven’t written any standalone programs—none that get input from the user, none that generate output. We have looked at the purely functional side of Haskell, where time does not exist. Functions always produce the same value given the same inputs. No matter how many times you call it. There’s no notion of a counter that increments. No side effects. Who on Earth would want a language like this? I can think of a few:
- People who want to mathematically prove their programs are correct. Proving correctness is very hard to do if you allow RAM to get twiddled with through assignment statements—especially if pointers are involved.
- People who want their programs to run very quickly. Far fewer copies of data need to be made if you know it will never change. Functional programming promotes an unparallelled ethic of sharing. There’s no need to insulate one environment from another, because no damage can be done. Imagine if you could never catch a disease. You wouldn’t mind fraternizing with lepers.
- People who want their programs to easily be distributed across multiple machines. Imagine we have three computers processing a dataset. If one of them updates a variable that the others rely on, we have a hazard on our hands. How do we make sure the other machines get the update? We have to use some sort of synchronization to ensure consistency. But if we don’t allow updates, each machine can do its work without concern for the others.
That said, at some point our feet need to touch earth. Time is a thing, and state does change. Haskell does recognize this, but it becomes a different language. It becomes the language of actions. In Haskell, an action produces a side effect. The most obvious side effect is console output. We can use
putStrLn to achieve this:
main = putStrLn "Goodbye, Pluto!"
If we want to issue several side effects, we can sequence them together in a
main = do putStrLn "Thanks, Obama!" putStrLn "You're welcome!"
This should look more like what you’re used to, right?
Other kinds of side effects exist. Like opening a web browser with
openBrowser, which is provided in module
Web.Browser by the
import Web.Browser main = do putStrLn "Thanks, Obama!" openBrowser "https://www.youtube.com/watch?v=79DijItQXMM" putStrLn "You're welcome!"
The documentation shows what kind of thing
openBrowser :: String -> IO Bool
Bool, but an
IO Bool. Haskell is serious about about keeping separate the world of side effects and the world of truth and identity. If you go get some data from the side effect world, it is tainted. Any result that a side effecting function gives back is packaged up in a capsule—an
IO—that isolates the contagion.
Time is another side effect. We can effect the passage of time in Haskell with
threadDelay. Here’s its interface:
threadDelay :: Int -> IO ()
We need to import
Control.Concurrent to get access to
That set of parentheses is the empty tuple. Sometimes it’s called unit. You can think of it as void. This function is used purely for its side effects, giving back no result. But notice that even that non-result is tainted. Also note that it takes milliseconds, so that number has to be pretty big to be perceptable:
main = do putStrLn "Thanks, Obama!" threadDelay 3000000
Dealing with the running process’ environment is also done in the world of side effects. Suppose we want to get the user’s username. We can use functions from the
System.Posix.User module. Its documentation tells us of the
getLoginName :: IO String
It gives us back a tainted string. Hmm… Let’s try using it:
main = do putStrLn "Thanks, Obama!" threadDelay 3000000 putStrLn $ getLoginName
This doesn’t work.
putStrLn doesn’t want your tainted junk. It wants a pure string. What do we do? We must open the sealed capsule. The bind operator
<- does that for us:
main = do putStrLn "Thanks, Obama!" threadDelay 3000000 username <- getLoginName putStrLn $ "You're welcome, " ++ username ++ "!"
The bind operator effectively unwraps the data from its
IO seal and adds a new variable into our execution environment. But here’s the thing: we can only bind like this inside another IO action. We can’t open up one of these capsules inside the world of truth and identity and statelessness. An IO action represents state, and Haskell makes it impossible to introduce state into the cleanroom that is pure functional programming.
What’s another side effect? How about input? There’s
getLine. Can you guess what its signature is?
getLine :: IO String
To echo out the typed line, we do this:
main = do line <- getLine putStrLine line
What if we wanted an
Int from the user? Well, we can write our own little helper that uses
getLine and then parses it:
getInt :: IO Int getInt = do line <- getLine ???
But then what do we do with it? Remember the
show function? It turns values of many different types into a string representation. Here we have the string and we want to go in reverse. The opposite of
read. However, since the view of the relationship in this direction is one-to-many, we must give
read a clue about what type we want:
getInt :: IO Int getInt = do line <- getLine let int = read line :: Int ???
read function is not a stateful one, so we don’t need to bind. We can do a regular assignment. Except regular assignments inside IO actions must be preceded by the
let keyword for reasons with which I’m not familiar.
Okay, now what about our return value? We have a beautiful and pure
Int, but it was born in the world of taint. So, we must encapsulate it. That’s what
return is for:
getInt :: IO Int getInt = do line <- getLine let int = read line :: Int return int
return effectively has this type signature:
return :: a -> IO a
It’s not really like a return in imperative languages, as it doesn’t do anything with control flow. It just generates a tainted capsule. If that capsule is the last expression of the
do block, it will get sent back to the caller, just as with pure functions.
Now we can write a function to get two numbers from the user and do something interesting with them:
main = do putStr "A: " a <- getInt putStr "B: " b <- getInt putStrLine $ show $ take a $ repeat b
Let’s deal with command-line parameters. This, like getting the username, involves communicating with the process, which is a stateful thing. We enter the world of side effects. The
getArgs function in
System.Environment has this signature:
getArgs :: IO [String]
Let’s extract out the first argument and turn into an
main = do args <- getArgs -- unwrap from the IO let arg0 = head arg -- pull out just the first let n = read arg0 :: Int -- parse the int
Erm… We should do something interesting here. Let’s print out all the factors of
n. How can we do this in Haskell? Through filtering!
factors n = filter (\x -> mod n x == 0) [1..n] main = do args <- getArgs -- unwrap from the IO let arg0 = head arg -- pull out just the first let n = read arg0 :: Int -- parse the int putStrLn $ show $ factors n
We should remind ourselves why factors are important. Wasn’t it the Babylonians who chose to use 360 for the number of degrees in a circle because 360 had so many ways to divide it evenly? They made it far easier to split a pizza amongst groups of various sizes.
Let’s do one last example, this time with a loop. Let’s print the first command-line parameter vertically. For, like, acrostics and crossword puzzles and stuff. We still don’t have loops, but we can use recursion. Here’s our function that “loops”:
downer :: String -> IO () downer  = return () downer (first:rest) = do putChar first putStrLn "" downer rest
main = do args <- getArgs let arg0 = head args downer arg0
One of your homework problems requires a loop until the user gets a right answer. We can’t use pattern matching for that, so let’s rewrite this using a more flexible construct:
downer list = if list ==  then return () else do putChar first putStrLn "" downer rest
For the remainder of our time today, let’s solve problems from Open Kattis:
Next time we’ll look at file input!
P.S. It’s time for a haiku!
I search “Russia prez”
I expect get some put-out
But I get Putin
P.P.S. Here’s the code we wrote together:
import Web.Browser import Control.Concurrent import System.Posix.User main = do putStrLn "Thanks, Obama!" -- openBrowser "https://www.youtube.com/watch?v=79DijItQXMM" threadDelay 3000000 username <- getLoginName -- let a = 5 -- let a = 6 -- let username = "dayne" putStrLn $ "You're welcome, " ++ username ++ "!"
getInt :: IO Int getInt = do line <- getLine let int = read line :: Int return int main = do a <- getInt b <- getInt putStrLn $ show $ replicate b a
downer :: String -> IO () downer  = return () downer (first : rest) = do putChar first putStrLn "" downer rest main = do putStr "Title: " line <- getLine downer line