discussion: Should we return Maybe when there is a possibility of invalid input? about haskell

[rbasso]

Looks like all-your-base will be merged soon and we will have an almost language-neutral specification.
I think it is really important, especially for Haskell, to have exercises that allow proper use of type classes to signal invalid inputs.

BTW, thanks for everything, @petertseng. 👍

[petertseng]

Seems good to me, and since I can close it, and you seem to also be in favor, I'll go ahead and do it. If anyone has more to add here I'm sure they can speak up here or elsewhere.

[rbasso]

Those exercises fell awkward and force unidiomatic solutions. It's desirable, at least, to avoid promotion of bad coding practices.

We should probably avoid demanding "error encoding" practices and partial functions most of the time.

I'm not against having a few exercises with not-so-idiomatic interfaces, as they force people to learn other features, but I believe that should be the exception, not the rule. If the problem's description doesn't specify a behavior on invalid input, it should return a Maybe.

I understand it's desirable to have exercises that allow a diversity of solutions, but the need - in Haskell - to type-check the solution with the tests forces us to choose an appropriate interface.

So, I agree! 👍

[rbasso]

If we are considering rewriting exercises, let's first see how this relates to x-common:

• binary.md says the solution should handle invalid input.
• trinary.md demands a result of zero on invalid strings.
• octal.md says to treat invalid input as octal 0, but that could refer to a single Char or the whole String.
• hexadecimal.md says the solution should handle invalid input.
• nucleotide-count.md says nothing about invalid input.
• phone-number.md talks about bad numbers, but does not say clearly what should be returned.
• All 4 base-conversion problem descriptions specify input as Strings.
• nucleotide-count says it receives a DNA string.
• phone-number talks about cleaning up user entered phone numbers.
• None of them have a JSON file specifying tests.

The way things are now, the four base-conversion exercises look essentially the same. We can correct their return types, but I guess the best thing is to ask in x-common why we have 4 almost identical exercises.

About nucleotide-count, we have to do something about it. Not only it demands a specific error message, but it also fails under lazy evaluation, because the solution may start outputting before evaluating the expression generating the error. Is it like this by design? If it is, we should move it near harder exercises.

About phone-number, I think we could change it.

So I suggest we solve this issue like this:

• Discuss in x-common if we need 4 identical base conversion exercises. (exercism/problem-specifications#276)
• Decide if we change nucleotide-count or move it down the list to avoid confusing beginners.
• Change phone-number's return type to a Maybe or an Either.

What do you think, @petertseng ?

Anyone else has anything to say about this? I would appreciate some feedback here. 😄

[petertseng]

I'm surprised to learn that the specification for the base-conversion exercises is so different. To change the specification in x-common requires notifying all implementing tracks of the change; that would be made simpler if they were combined. We'll see what comes of that.

Decide if we change nucleotide-count or move it down the list to avoid confusing beginners.

If you'd like to know why it is this way, we can look at the commit where it was added. noting that there was discussion on this very issue.

Even knowing the rationale, I still slightly favor changing nucleotide-count to use Maybe. To me it doen't seem to right to ask implementors to write a function that uses error when Maybe is available. I could be convinced otherwise if we think the benefits (of showing students how to deal with error?) are worth it.

Change phone-number's return type to a Maybe or an Either.

Looks like nothing stops us from doing this, good.

[rbasso]

To try increasing visibility and maybe get a little more participation, I think we should open two issues:

• What do you think about rewriting nucleotide-count to return Maybe or Either?
• What do you think about rewriting phone-number to return Maybe or Either?

But first, it would be nice to have a more detailed proposal. What would be the exported functions' type?
Edit: Better to open the issues earlier to get more feedback.

[rbasso]

Considering that exercism/problem-specifications#276 will probably take some time to finish, I don't see any problem in opening a new issue to change the return types of binary, trinary, octal and hexadecimal too.

That's up to you, @petertseng, if you think it's worthy.

[petertseng]

It's altogether possible we could just go ahead and change the four base conversion exercises if the consolidation of all-your-base is still a ways away. Though depending on how things go with exercism/problem-specifications#276, a better tomorrow may not be that far away, in which case we might just favor being lazy and rather focus the efforts on getting all-your-base implemented for this track (and part of that will be to use either Maybe or Either). I think I may like to see how exercism/problem-specifications#276 progresses by the end of the week to see if we can simply prepare for the better tomorrow.

[rbasso]

You're right! exercism/problem-specifications#276 is going faster than expected.

[rbasso]

Considering that...

• binary, trinary, octal and hexadecimal will be deprecated by exercism/problem-specifications#279
• all-your-base was added to x-common by exercism/problem-specifications#280 and is pending implementation in issue #167.
• phone number was changed by #163.
• nucleotide-counthas its own issue #157 and the PR #165.

...and that the initial demand was...

The question is simply: For the exercises that already test invalid inputs, should they return Maybe as the result?

I think the initial demand was solved and this issue can be closed. Also, we can deal with other exercises that do not check for invalid inputs on their own issues on a case-by-case basis, as we are doing in #166.

Are you satisfied with that solution, @petertseng 👍 ❓