[Scheme-reports] Comments on draft 6 Vitaly Magerya (18 Feb 2012 15:31 UTC)
Re: [Scheme-reports] Comments on draft 6 Jussi Piitulainen (18 Feb 2012 15:56 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (18 Feb 2012 23:16 UTC)
Re: [Scheme-reports] Comments on draft 6 Alex Shinn (19 Feb 2012 05:24 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (19 Feb 2012 19:23 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (19 Feb 2012 22:39 UTC)
Re: [Scheme-reports] Comments on draft 6 Vitaly Magerya (20 Feb 2012 15:53 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (20 Feb 2012 18:50 UTC)
Re: [Scheme-reports] Comments on draft 6 Vitaly Magerya (21 Feb 2012 15:34 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (21 Feb 2012 16:25 UTC)
Re: [Scheme-reports] Comments on draft 6 Alex Shinn (23 Feb 2012 01:27 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (23 Feb 2012 03:27 UTC)
Re: Comments on draft 6 Arthur A. Gleckler (21 Feb 2012 05:39 UTC)
Re: Comments on draft 6 Arthur A. Gleckler (21 Feb 2012 06:29 UTC)
Re: [Scheme-reports] Comments on draft 6 John Cowan (22 Feb 2012 22:34 UTC)

Re: [Scheme-reports] Comments on draft 6 John Cowan 21 Feb 2012 16:25 UTC

Vitaly Magerya scripsit:

> > 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 see that I forgot to include the definitions in my email:

A \defining{fresh} location is one that is distinct from every
previously existing location.

When a procedure is said to return a \defining{newly allocated} object,
it means that the locations in the object are fresh.

> 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.

No, only implementations that purport to provide a high-accuracy version
of (current-second).

> 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 agree, but unfortunately the "perfect jewel" vision of Scheme
prevailed; people wanted a flawless but impracticable timescale.

> 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.

You're probably right.  For SRFI-18, time duration is all that counts.

--
A few times, I did some exuberant stomping about,       John Cowan
like a hippo auditioning for Riverdance, though         cowan@ccil.org
I stopped when I thought I heard something at           http://ccil.org/~cowan
the far side of the room falling over in rhythm
with my feet.  --Joseph Zitt

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