Marcin 'Qrczak' Kowalczyk wrote:
> So you can have a difference of 3 months (whatever it means),
> or 14 days, but you can't have 3 months + 14 days?
3 months means "Add 3 to the month and roll over the day, if necessary".
14 days means "Add 14 to the day, and roll it over if necessary".
The two operations are not commutative. For example start with March 20th.
March 20th + 14 days = April 3rd so (March 20th + 14 days) + 3 months = July 3rd
March 20th + 3 months = June 20th so (March 20th + 3 months) + 14 days = July 4th
So I don't think allowing "3 months + 14 days" is a good idea. An alternative
would be simply to declare
TimeDiff = ClockTime -> ClockTime
but then it wouldn't be so easy to extract from a TimeDiff in days the actual
number of days.
Simon Peyton-Jones wrote
> I'd suggest *not* putting diffClockTimes in the class.
> You'll get lots of ambiguities.
> e.g. (a + (b - c))
> what sort of "-" do you mean?
>
> Better, I think, to say
> diffMinutes
> diffHours
> diffMonths
> diffDays
> etc.
Yes, I think Simon P-J has a point there. I was thinking that people would
write
(diffClockTimes t1 t2) :: TimeDiffMinutes
(if they didn't then in the above example the compiler would complain about
unresolved overloading). Perhaps putting it in the function name would be
less confusing.
> And once you have that, maybe they could all return the
> same type (TimeDiff) and then the need for the class goes away.
> diffMinutes :: ClockTime -> ClockTime -> TimeDiff
I suppose TimeDiff is then a disjunction (Minutes of Int | Days of Int | etc.)
But I don't really see the point. The type is now considerably less efficient
and the compiler has to worry about an entirely bogus matching failure in
cass (diffMinutes t1 t2) of
Minutes N -> [blah]
What is so bad about having another class anyway?
