More Haskell L99
Posted by Daniel Lyons Tue, 12 Dec 2006 08:13:36 GMT
I’m up to #23 and just now hit the first snag. Well, the second snag. An earlier problem depended on infinitely nested lists, which you can’t do in Haskell without making a new data type and I didn’t feel like doing it. (#11).
A couple observations:
- In general, the Haskell implementation is very short. The average length for these solutions is 3.7 lines of code (including types, when the compiler made me add them).
- In general, the Haskell solution is quite quick to arrive at. Things that would be difficult to figure out how to express in Lisp seem to come together more nicely because there’s less between you and your idea, syntactically (believe it).
- When you’re not sure what the hell you’re doing, it helps to add a type signature.
- If you added a type signature and it’s still not buying it, actually read the error message. All of the messages I’ve gotten from GHC have been extremely helpful, when I’ve stopped to actually, you know, read them.
- I’m a little surprised at how easy these problems are. There have only been two which struck me as intrinsically more difficult (#6 and #9). This is either because I’ve read the Little Lisper or because I am just more familiar with functional programming than I used to be.
I guess it could also be because I cheat left and right: in #18, I have this line of code: slice l 1 y = take (y-1) l, and my implementation of #22 is just range x y = [x..y]. But hey, Haskell is more expressive. What can I say?
I think I may post the file containing all my solutions when I’m done. It’s 160 lines of code right now (I didn’t include comments in the average above).
