Skip to content

Clock exercise shouldn't use Num because that promotes bad behavior #695

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
isovector opened this issue Jul 24, 2018 · 2 comments
Closed

Comments

@isovector
Copy link

The clock exercise is really bad. The only meaningful semantics of a clock are of an absolute point in time, which aren't closed under addition. Thus Num is an exceedingly bad instance to give for them, and the exercise itself suggests ignoring most of the methods.

A much better solution is to have a addDelta :: Hour -> Minute -> Clock -> Clock

@petertseng
Copy link
Member

While whoever wrote this exercise probably thought it was handy that you can use the + and - operators, I believe @isovector is correct here; it doesn't actually make sense to use them. The operation 08:20 + 09:01 (where both operands denote a time) is not sensible (the answer is NOT 17:21) because logically I can't add two times together. I can add nine hours and one minute to eight twenty, but I can't add one past nine to eight twenty.

I can add a duration to a time and get another time.
I can subtract a duration from a time and get another time.
I can subtract two times and get a duration. (but this is not covered in this exercise)
The typeclass Num does not express these desired semantics.
As we can see in http://hackage.haskell.org/package/base-4.11.1.0/docs/Prelude.html#t:Num , Num implies that you can do a + a and get an a, and as discussed above that is not sensible for times.
Therefore, as it currently stands, the clock exercise is not well-typed.

The proposed addDelta :: Hour -> Minute -> Clock -> Clock is a reasonable proposal that deals with the problems.

Assuming I haven't missed any files, these are the files that should be changed to resolve this issue:

@petertseng petertseng changed the title Clock exercise promotes bad behavior Clock exercise shouldn't use Num because that promotes bad behavior Jul 31, 2018
@tiniuclx
Copy link
Contributor

I think the proposed changes make sense, I'll see what I can do about this. I'll have a go at solving the exercise as-is, then I'll write up a pull request for this issue.

tiniuclx added a commit to tiniuclx/haskell that referenced this issue Sep 20, 2018
As discussed in issue exercism#695, a negative time doesn't make sense.
The semantics of `negate` will be replaced with `addDelta` with
negative parameters.
petertseng pushed a commit to tiniuclx/haskell that referenced this issue Sep 27, 2018
petertseng pushed a commit to tiniuclx/haskell that referenced this issue Sep 27, 2018
As discussed in issue exercism#695, a negative time doesn't make sense.
The semantics of `negate` will be replaced with `addDelta` with
negative parameters.
petertseng pushed a commit to tiniuclx/haskell that referenced this issue Sep 27, 2018
The previous track-specific tests all made the assumption that Clock is
a Num instance. Since this is no longer the case, they have been
removed.

Closes exercism#695
petertseng pushed a commit to tiniuclx/haskell that referenced this issue Sep 27, 2018
petertseng pushed a commit to tiniuclx/haskell that referenced this issue Sep 27, 2018
As discussed in issue exercism#695, a negative time doesn't make sense.
The semantics of `negate` will be replaced with `addDelta` with
negative parameters.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants