secret-handshake: use cases from x-common

[petertseng]

This removes the string cases; the function-under-test is now only
obligated to accept integers.

Note that the now-deleted HINTS.md accepted that this API design was
bad, so it is good to get rid of it.

---

Reviewers: this is a bit of a shame, as we are getting rid of a unique request of students (to make a function take both a string and a number). But I also think that this problem might be a bit too early to make this request. Do you want to keep it and/or revive this concept in another problem?

The only other problem in which we request students to implement a typeclass is in Clock.

[abo64]

I feel sorry about the gone typeclass, too.

But then again, there are many more Haskell-specific constructs for which it would be nice to have especially designed exercises (just think of all the various Monads).
Sounds like true fun - for true Haskell aficionados.
How far should we go? What should be the scope of exercism.io here?

[petertseng]

Trying to think about how http://tinyletter.com/exercism/letters/what-exercism-is-and-isn-t and exercism/exercism#3113 apply to us. Libraries seem to go a bit far (even the lens-person exercise is a bit dubious, but now many languages have adopted it - it's useful for immutable nested data). But typeclasses and introducing the various monads seem reasonable, since they are often seen when using the language?

If we do need to make some Haskell specific exercises, then exercism/DEPRECATED.trackler#22

[petertseng]

By the way, if we think we are not yet ready to remove the string cases, I can leave them in - then the only update will be to use the x-common cases.

[abo64]

Thanks for the links, interesting reads!
I also find it enticing to add language-specific (and then even library-specific) exercises, there is always so much more to learn. But I also see the danger to open this can of worms.

Now having said that, here is my opinion:
Those language-specific constructs or libraries do (or at least should) exist for a reason, namely to solve a concrete problem in an easier/more elegant/more fun way. If we can distill this concrete problem in an exercise it should become language-/library-independent and therefore suitable for x-common, too.

Let me be be more concrete:
In the Scala track we have added this topic of Function Overloading. Now I could imagine that this could be sold as almost language-independent? If so let's have a specific exercise for that and we have our typeclass (as used in secret-handshake) back.

Monads might be not so simple. Haskell's built-in support of the concept in the language itself is still exceptional. But it is at least mainstream in the FP community. So do we want to have "Monad" as a general topic, too? Most FP-capable languages have at least popular libraries. Is that enough?
If not then again we can at least pick or add some suitable exercises that can be solved so much easier with the respective monad (but can of course also be solved without it). And then either force the monad in the Haskell track by, say, having it as the exported function's return type. Or gently suggest it in the HINTS.md.