all-your-base: Add exercise to allow deprecation of binary, trinary, octal and hexadecimal.

[rbasso]

It was decided in exercism/problem-specifications#276 that all-your-base will eventually replace the four base conversion exercises we currently have: binary, trinary, octal, hexadecimal. But, before deprecating them, we need to implement all-your-base in this track.

This exercise's interface could be something like this:

module Base (rebase) where

rebase :: Integral a => a -> a -> [a] -> Maybe [a]
rebase b1 b2 ...

Where b1 is the the input's base and b2 the output's base.

There was a long discussion in the PR exercism/problem-specifications#280 that added all-your-base about how the corner cases should be handled, and it was decided that each track will have to choose the most idiomatic solution.

IMHO, we should follow most of the semantics used by the package digits, but also checking for invalid digits and bases. This means that the canonical representation for the digits of zero would be zero [], and that leading zeros would be always superfluous:

rebase 2 10    [] = Just  [] -- Zero has no digits
rebase 2 10   [0] = Just  [] -- One zero digit is the same as []
rebase 2 10 [0,0] = Just  [] -- Multiple zero digits are the same as []
rebase 2 10 [0,1] = Just [1] -- Leading zeros are ignored
rebase 2 10 [1,7] = Nothing  -- Invalid digits return Nothing
rebase 2  1 [1,0] = Nothing  -- Invalid bases return Nothing

I believe this would allow for some really simple and elegant solutions, but some people prefer to represent the digits of zero as [0].

It's up to the one writing the PR to decide how the cases undefined in all-your-base.json should be treated! 👍

[petertseng]

some people prefer to represent the digits of zero as [0].

Depending on how much demand there is, perhaps it would be appropriate to make the tests flexible such that either [0] or [] are accepted as representations of zero?

Of course, there would be questions such as "So, if we accept either [0] or [] for zero, does that mean that for a representation of one would accept either [0, 1] or [1]?" It's possible the answer to that question would be "No, we should only accept [1] as all leading zeroes should be removed from the answer with the sole exception that zero can have a single zero".

I have not thought about this deeply enough to say that this above is indeed what I will recommend, but I'll put it as a suggestion in case someone else wishes to take it.

[rbasso]

I didn't find an easy way to accept multiple answers, so I have not implemented this feature.

One of the major problems is how to keep reasonably descriptive error messages from HUnit while accepting multiple answers. If anyone knows how to do it, please tell me!

I inserted this exercise just after atbash-cipher, but maybe there is a better position for it.

Any ideas?

[petertseng]

One of the major problems is how to keep reasonably descriptive error messages from HUnit while accepting multiple answers. If anyone knows how to do it, please tell me!

Oof, good question. I also baked my own when implementing https://github.com/exercism/xhaskell/pull/107/files . I don't remember how hard I looked in HUnit to see whether it natively supports allowing multiple answers, but if neither of us found anything perhaps that is indicative.

[rbasso]

I miss some extra functionality in HUnit, but I believe we'll have to keep using it for a while. It's the only test library I found in the Haskell Platform 😞, and - given the way we provide the exercises it would be difficult for some users to get other libraries installed.

I was playing with tasty and criterion and started wondering if in the future we could provide more flexible tests and some optional benchmarks...

tasty-fail-fast could be useful for exercism, but I'm still trying to find a way to enable it by default. I have no idea about if it can allow multiple answers.