-
-
Notifications
You must be signed in to change notification settings - Fork 195
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
Comments
While whoever wrote this exercise probably thought it was handy that you can use the I can add a duration to a time and get another time. The proposed Assuming I haven't missed any files, these are the files that should be changed to resolve this issue:
|
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. |
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.
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.
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
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.
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
The text was updated successfully, but these errors were encountered: