John Cowan wrote:
> I have standardized on the terms "fresh location" and "newly allocated
> object" (or list, string, vector, etc.) and defined both, the first in
> Chapter 4 and the second in Chapter 6 (though there are a few uses of
> "newly allocated" in Chapter 4).

Sounds good.

> I personally agree that Posix time would have been better, but was
> outvoted.
>
>> There are multiple things I would use current-second for. In the
>> absence of proper date library I may try to derive wall clock time
>> from current-second. Unfortunately to do this using TAI you'd need a
>> constantly updating leap second table, and this is impractical.
>
> Actually, such tables are available from IERS and from NIST and other
> national time organizations over the Internet.  They need not be
> continuously updated, only every month (or in practice every six
> months).

Yes, that's what I meant by impractical: periodically downloading
files over internet to keep timers working. You'd need to ship a
piece of software that does that with every scheme implementation.
You'd also need to ship some cryptography to make sure that whatever
you're downloading is not spoofed. Not impossible, sure, but I'd
rather not have to explain why my scheme system requires this kind
of maintenance, while all the other languages do not. I'd rather
have it use whatever data is already there on my system.

>> I see. Is this an important optimization? Are there implementations
>> that have similar functionality (i.e. fixnum-based monotonic timer)?
>
> SRFI 18 does not require a fixnum or even integral result, but permits
> an implementation-specified epoch without saying why.  I can think of no
> other reason.

Since SRFI 18 has a separate "time object" thing, I don't think
that saving an allocation is what it's about (i.e. I don't think
time objects are meant to be immediate; the SRFI says they are
not integers).

The epoch is probably unspecified because native timers may use
different ones on different platforms, and you generally don't care
about it anyway. Besides, you can't have a monotonic clock with
epoch defined as a fixed date, because it would necessarily jump
when user adjusts current date. This does not happen with e.g.
clock_gettime(CLOCK_MONOTONIC), the epoch of which is not specified.

>> I would have guessed that most just provide an inexact number of
>> seconds, and not bother to save a memory allocation on this operation.
>
> My multiple-Scheme test system is down right now.  Chibi provides
> SRFI-18 and uses the Posix epoch, which currently is a fixnum.

Well, Chibi currently has this:

    (define current-jiffy current-second)
    (define (jiffies-per-second) 1)

So...

_______________________________________________
Scheme-reports mailing list
Scheme-reports@scheme-reports.org
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports