Day 2 of Haskell mostly focused on features related to higher order functions, after going through so many functional languages in this book, arts of this section felt somewhat repetitive (anonymous functions, filter, map, fold, etc), though they were kept fairly brief. The standout topics from this section are probably, currying and partial application. Partial application allows you to set some of the arguments of a function (producing a function that takes fewer parameters) and makes creating collections of functions, with varying levels of genericness, convenient. There was also a brief description of function composition which i didn't find particularl clear, but i did find a clearer one here.
The exercises, while useful to get a hold of the basic syntax and form of the language, didn't feel particularly specifically suited to exposing unique aspects of Haskell (though this probably comes from the familiarity gained while looking at functional programming languages over the previous few chapters).
I've tried to keep add more comments directly to the code so that the blog posts wouldn't feel as redundant. All the code for this exercise is available here.
Q1
For the first question, I thought I would try and write something more 'imperative' feeling at first, in particular bubble sort. It does feel a little less natural (at least for someone inexperienced in the language like myself) to implement this algorithm as some of the things I'd be used to falling back on to implement it (i.e. state) are not as easily manifest (for good reason in the grand scheme of things). But i do find it interesting to try and see how I would approach trying to do something imperative feeling. With the bubblesort I got bored before even figuring out how i would keep track (kids and their darn state! keep off my lawn!) of when the list gets sorted, so that I can exit a bit earlier, as is I just iterate enough times that the algorithm guarantees the output will be sorted.
The quick sort implementation was really straightforward to do, and list comprehensions show their awesomeness and concision again! The only tricky thing here (and in q2 which i won't include here) was doing division! This was just because of my lack of familiarity with the type hierarchy and return types of some functions. length lst returns an Int which apparently doesn't define a division operator, we must turn it to an Integer with fromIntegral to do the division. I don't know enough about why this is organized this way to say if this is a wart or a feature, I can think of some reasons why it would be a feature, you can prevent some kinds of accidental data loss, but don't really know.
Q3
Question 3 was fun to write, and it took me a few minutes to remember how to convert a string to a number (i remember fondly when math was that easy, and we were summing 'thousands' and 'hundreds' and 'tens'...). The type inference really shone though here, i'd attempt to write what i thought was the correct signature, and when that didn't work (got tripped up by the division thing again and the difference between Num and Fractional), i could just turn of my guess, compile the code and ask haskell. Its really good and can quickly point to the part of the function that is ambiguous with regards to the signature you are targeting (or implying by the functions you are using).
Q4
I'm not sure i properly understood question 4, and suspect its not well formulated. I am not sure what its asking can be done with function composition (but i'm also a newb at Haskell soo there is my dilemma). I've seen a few other posts online solve this with zip, but that doesn't seem to me to be the same as function composition (the 'dot' operator). I'd be really curious if there is a solution or interpretation I am missing.
Anyway, that was day two. Just one more section and I'll be at the end of the book! (though one language short of a Tate's dozen (7) :-) I do plan on adding a language not included in the book so stay tuned.