Heh, yeah. I'm aware. I wouldn't use it if I wasn't writing for limited test cases.

The instructions and the sample test cases don't match the final test cases; nothing in the spec makes it clear one should expect lowercase or numeric input, and neither are present in the sample cases actually given visibly. Further, the test results for lowercase vs. uppercase would be wrong in terms of an actual multi-tap phone entry anyhow (here they match the same number of keypresses either way, where on an actual phone, and depending on model, an additional shift or even extra taps would be necessary).

I had this problem at first as well; the type signature is the problem. If you comment it out and let Haskell infer type, it might work. I'm not sure what the issue is there.

Wow, I can't believe I didn't think about doing a mutually recursive method for the even/odd list portion. Constraining the doubling to do the "add the digits" bit is pretty smart too. I just mapped over the digits by length of string representation instead.