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.