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

fromJust :S

The description has been updated to reflect ignoring upper vs lowercase.

Numeric input is explicitly mentioned in the example in the description (the sample is "WHERE DO YOU WANT 2 MEET L8R"). It is intentionally left out of the example test cases to give the student something to identify and add to their own test cases after reading and understanding the problem statement.

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.