This page is part of the web mail archives of SRFI 19 from before July 7th, 2015. The new archives for SRFI 19 contain all messages, not just those from before July 7th, 2015.
> Yes, you have a point. But let us move forward -- I'd like to lobby > for starting a *new* convention. No irritating terminal ?'s on comparison > functions -- <=, <, =, >, >= predicates. Moving forward is not always a good thing, for example if you are on the edge of a precipice. ;-) However, if you can convince the RnRS authors to drop the ? on string=?, etc (but not on pair? etc) I'm 100% behind you (... on the edge of the precipice). > However, if you use the names CURRENT-DATE & CURRENT-TIME, you can't make > each function work as both the current-time fetcher and converter with > optional arguments, as I did. I think using DATE & TIME makes for a very > small, simple interface. You simply use the name corresponding to the kind > of thing you want; if you are doing a conversion, then you give the parameter. > End of story. I was suggesting (current-date) and (current-time) to get the date and time, and (date->time date) and (time->date time) to convert between them. > Making time a distinct datatype, instead a number, has plusses & minusses. > I have mixed feelings. > - Plusses > Increased error detection > Can represent time as pair of ints -- second & subsecond precision. > ...which allows hiding leap seconds in the subsecond part, a la > Kuhn's proposal. Also, you can overload (mutex-lock! mutex timeout) so that it accepts absolute timeouts (a time object) and relative timeout (a real representing a number of seconds from now). > - Minusses > Cannot use arithmetic ops to do time calculations -- very annoying Hmmm... **very** annoying???? > Must cons to generate a time; not low overhead. This is bogus. Many fixnum representations only cover the range -2^29 .. 2^29-1 so the number of seconds since the epoch is already a bignum, and nanoseconds also overflow into bignum territory. Using a flonum (counting the number of microseconds since the epoch) is probably faster and more space efficient. Encapsulating this flonum in an abstract datatype is good so that the implementation dependent choice of tick (the microsecond today, the picosecond in 10 years (when we have 128 bit flonums!!!)) is hidden from the user. Moreover, getting the current time from the OS can be quite expensive (I measured about 5 microseconds on Linux RH 6.1 with a 600MHz Athlon, which is the equivalent of 3000 machine cycles!!!) so you will not notice the overhead of allocation. Marc