Odds and Ends in Haskell: Folding, I/O, and Functors. Adapted from material by Miran Lipovaca. The foldl function. We’ve seen a particular pattern quite often with lists: - base case on empty list - some operation with the head, plus a recursive call on the tail
Folding, I/O, and Functors
Adapted from material by Miran Lipovaca
We’ve seen a particular pattern quite often with lists:
- base case on empty list
- some operation with the head, plus a recursive
call on the tail
This is such a common pattern that there is a higher-order function to handle it.
Inputs: a function, a initial starting value (which we’ll call the accumulator, although it can have any name) and a list to “fold up”
sum'xs=foldl(\accx-> acc +x)0 xs
The binary function is applied to the accumulator and the first element (in foldl), and produces a new accumulator. Then called again with the new accumulator and the new first element of the list, until the rest of the list is empty.
In fact, we can write this function in an even shorter way, since functions can be returned as parameters:
The lambda function on the previous slide is really the same as (+), and we can omit xs because the function written above will just return a function that takes a list as input.
Another example: elem since functions can be returned as parameters:
Returns True if the variable is present in the list
Other functions: since functions can be returned as parameters:
- Foldr is the same, except starts with the end of the list (and accumulator is the second input to the function).
- Scanl and scanr work just the same, but return all intermediate accumulator values in a list.
- foldl1 and foldr1 work just the same as foldl and foldr, but don’t need to provide a starting value - they assume first (or last) element of the list is the starting value.
So far, we’ve worked mainly at the prompt, and done very little true input or output. This is logical in a functional language, since nothing has side effects!
However, this is a problem with I/O, since the whole point is to take input (and hence change some value) and then output something (which requires changing the state of the screen or other I/O device.
Luckily, Haskell offers work-arounds that separate the more imperative I/O.
A simple example: save the following file as helloword.hs since functions can be returned as parameters:
Now we actually compile a program:
What are these functions? since functions can be returned as parameters:
So putStrLn takes a string and returns an I/O action (which has a result type of (), the empty tuple).
In Haskell, an I/O action is one with a side effect - usually either reading or printing. Usually some kind of a return value, where () is a dummy value for no return.
An I/O action will only be performed when you give it the name “main” and then run the program.
A more interesting example:
Notice the do statement - more imperative style.
Each step is an I/O action, and these glue together.
More on getLine: name “main” and then run the program.
This is the first I/O we’ve seen that doesn’t have an empty tuple type - it has a String.
Once the string is returned, we use the <- to bind the result to the specified identifire.
Notice this is the first non-functional action we’ve seen, since this function will NOT have the same value every time it is run! This is called “impure” code.
An invalid example: name “main” and then run the program.
What’s the problem? Well, ++ requires both parameters to have the same type.
What is the return type of getLine?
Another word of warning: what does the following do?
You can use let statements inside do blocks, to call other functions (and with no “in” part required):
Note that <- is for I/O, and let for expressions.
Return in haskell: NOT like other languages. functions (and with no “in” part required):
What is return? functions (and with no “in” part required):
Does NOT signal the end of execution! Return instead makes an I/O action out of a pure value.
In essence, return is the opposite of <-. Instead of “unwrapping” I/O Strings, it wraps them.
More advanced functionality is available in Control.Monad: functions (and with no “in” part required):
(Will indefinitely ask for input and print it back out capitalized.)
Functors are a typeclass, just like Ord, Eq, Show, and all the others. This one is designed to hold things that can be mapped over; for example, lists are part of this typeclass.
This type is interesting - not like previous exmaples, like in EQ, where (==) :: (Eq a) => a -> a -> Bool. Here, f is NOT a concrete type, but a type constructor that takes one parameter.
Compare fmap to map: functions (and with no “in” part required):
map :: (a -> b) -> [a] -> [b]
So map is a lot like a functor! Here, map takes a function and a list of type a, and returns a list of type b.
In fact, can define map in terms of fmap:
Notice what we wrote: functions (and with no “in” part required):
We did NOT write “instance Functor [a] where…”, since f has to be a type constructor that takes one type.
Here, [a] is already a concrete type, while  is a type constructor that takes one type and can produce many types, like [Int], [String], [[Int]], etc.
Another example: functions (and with no “in” part required):
Again, we did NOT write “instance Functor (Maybe m) where…”, since functor wants a type constructor.
Mentally replace the f’s with Maybe, so fmap acts like (a -> b) -> Maybe a -> Maybe b.
If we put (Maybe m), would have (a -> b) -> (Maybe m) a -> (Maybe m) b, which looks wrong.
Using it: functions (and with no “in” part required):