> 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