Am Mi., 2. Nov. 2022 um 22:58 Uhr schrieb Marc Nieper-Wißkirchen <[email protected]>: > > Am Mi., 2. Nov. 2022 um 20:54 Uhr schrieb John Cowan <[email protected]>: > > > > > > > > On Wed, Nov 2, 2022 at 12:55 PM Marc Nieper-Wißkirchen > > <[email protected]> wrote: > > > >> @Marc: Thanks for helping me to get my interface right and for the > >> "seconds+" naming suggestion. > > > > > > I'd like to hold the trailing-plus convention for generic functions, so > > that e.g. `length` continues to be for lists only and `length+` (pronounced > > "length-plus") is generic over traversables. > > "length+" is already in SRFI 1 and is a safe version of "length". It > is not generic. > > Anyway, the "+" suffix has also other established uses, namely for > addition as in "fx+" or "fl+". In "seconds+", it is used in this > sense. I hardly see a source of confusion here. One could argue > whether "time+/second" would be better. > > > It seems to me that "add-seconds" is satisfactory. However, some account > > should be given of the minimum granularity of time objects. Seconds are > > far too long; for example, Posix terminal timeouts are measured in > > deciseconds, and the minimum resolution of a Posix real-time clock is 20 ms > > (probably derived from 50 Hz power; 60 Hz power will provide 16.66... ms > > resolution). > > The argument is a real number so, in principle, there is no limit. > Even single floats would suffice for the purpose of SRFI 226. The > specification of (srfi :226 control times) is minimal on purpose. It > is easy to add extra constraints outside of SRFI 226 to the resolution > of time objects. For SRFI 226 there is no guarantee altogether > because the thread scheduler need not be real-time. > > If you think it helps, I can add a comment saying that it is > recommended that the granularity is at least a millisecond. > > >> > > As for (nanoseconds-from-now N) I think it is sufficient to just use > >> > > seconds. In 20 years nanoseconds might be “old school” and you really > >> > > want picoseconds, in 50 years femtoseconds, etc. > > > > > > That seems extremely unlikely, as a light-femtosecond is about the size of > > an average virus. We are not, even in 50 years, going to have > > computational components that small. > >> > >> > I would be fine with just seconds; others have voiced the wish for > >> > nanoseconds, including John. > > > > > > The Posix clock routines return seconds and nanoseconds, though that does > > not mean the clock actually ticks in nanoseconds. > > A (nanoseconds+ TIME N) can be easily added, but this can be left for > a future SRFI concerned with fleshing out the (srfi 226 :control > times) interface (e.g. by explaining it in terms of a derived version > of SRFI 19). > > I can add a comment about it.
Added two notes (see my personal repo).
