On Wednesday 02 February 2005 05:42, S. Alexander Jacobson wrote:
The overall goal here is to make sure that when you have a function that takes a Date or Time type, the values are consistent with the intended invariants of the type!
Right. But see below.
On Wed, 2 Feb 2005, Marcin 'Qrczak' Kowalczyk wrote:
or 4 digits. Why not define year like this:
newtype Year = Year Int -- don't export constructor mkYear century centyear = Year (100*century+centyear) mkBigYear millenium cent centyear = ...
Because it's easier to use the actual year number.
Ok, but we have the common enough case of 2 digit vs 4 digit year that we might as well handle it. The Y2K problem is an existence proof
I support most of your suggestions, but this one makes no sense at all. Just use twoDigitYear year = year `mod` 100 if you really want only the last two digits.
The type of hour minute and second should protect the user from 28 o'clock and making appointments for 31:101 PM So we probably want:
data Hour = H0 | H1 | H2 ... H23 data Minute = M0 | M1 | M2 ... M59 data Second = S0 | S1 | S2 ... S59
Again, it's simpler to use actual numbers. These values almost never appear as literals in a program, so they would have to be converted to/from numbers anyway, which is unnecessary and no other language does this.
Its only simpler to use actual numbers if the library does not provide the services to make it easy to use these values.
Let us not talk so much about data representations. Most important is the interface. We can have Data as an ADT and use constructors that check validity of month & day values and throw exceptions if check fails. Same with hours, minutes, etc..
And we should certainly prefer to produce errors at constructor time rather than at destructor time. It should not be possible to construct a Time like 43:84:00.
Yes.
There are also lots of contexts where you want a time but not a date e.g. an alarm clock....
And there are contexts where you want a weekday and hour/minute but not a month or second (a weekly schedule), contexts where you want month/day but not a year (a holiday with a fixed date) etc. Where to stop?
Are you seriously saying that you never have use for a Date without a Time? On what date were you born? In my particular case, I am storing a lot of dates and don't also want to consumer memory for Time data that I won't use.
I don't buy the memory wasting argument, but still aggree, that a (Calendar.Gregorian.) Date should only contain year, month, day. The other thing should be TimeOfDay. And then we would have Time = (Date, TimeOfDay) (or a data type instead of tuple). My argument: A thing should be what its name says it is. When I talk about date I mean date and not date plus time of day. Ben -- "The CIA is Wallstreet. Wallstreet is the CIA." (Mike Ruppert)