[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