Am Mi., 2. Nov. 2022 um 22:58 Uhr schrieb Marc Nieper-Wißkirchen
<xxxxxx@nieper-wisskirchen.de>:
>
> Am Mi., 2. Nov. 2022 um 20:54 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
> >
> >
> >
> > On Wed, Nov 2, 2022 at 12:55 PM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> 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).