Am Mo., 3. Okt. 2022 um 15:21 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Mon, Oct 3, 2022 at 7:39 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>>
>> There is possibly an alternative solution, namely abstract time
>> objects (like those of SRFI 18).  This solution would make it an error
>> if the TIMEOUT parameter is a raw number.  Instead, it would have to
>> be wrapped into a call of (jiffies->time ...) or (seconds->time ...)
>> or (jiffies->time-delta ...) or ...
>
>
> I like this idea.  However, the time objects of SRFI 18 are integers measuring 1/10 seconds.

I would make the time object opaque and of a disjoint type to catch
typing errors.

> I recommend that the time objects of SRFI 19 be used instead: they are integers representing seconds and nanoseconds plus a flag indicating the significance, which in this case should be the symbol `duration`.  (SRFI 170 also has time objects, but I intend to create a post-finalization note recommending the use of SRFI 19 time objects as an alternative, in order to have a uniform representation of time.)

I don't understand the logic behind the design choices of SRFI 19
fully. For the purpose of SRFI 226, it is specifying much more than
what is needed (and the split between seconds and nanoseconds is
arbitrary in view of this SRFI). But we probably want more than just a
duration but also an absolute time to specify a concrete time in the
future.

In any case, the procedures I propose, namely

time?
time-delta?
jiffies->time
time->seconds
etc.

could be implemented in terms of an implementation of SRFI 19. The
only clash calling for a rename would be `time?` because, in SRFI 19,
a time duration is also a time. I don't want to follow this because it
is like comparing apples with pears.