|
[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)
|
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